The URL shown here is making the rounds. WARNING: don’t visit this URL unless you’re prepared to have your browser crash (the screenshot is from a current trunk nightly, which survives the Flash crash due to Out Of Process Plugins support).
I’m getting all verklempt.
Yesterday I landed bug 538910, which introduces some new UI for when a plugin crashes. This builds on top of the fantastic Out Of Process Plugins (OOPPs) work from the Electrolysis team, which allows the browser to keep running even after a plugin dies. So, now that crashes from plugins like Flash, Java, Silverlight, and Quicktime don’t take down Firefox, we need to show the user something to indicate when a plugin has a problem and how to deal with it.
A picture is worth a kiloword, so let’s start with that:
When a plugin crashes, we now show a placeholder (as in the pic above) to indicate that the page is missing some expected content. The browser runs a single plugin process (per plugin type), which is shared across all tabs and windows, so any page using a plugin when it crashes will have it replaced with this UI. But if the plugin on the page is sized too small to show the UI (text and icon), we’ll instead show a notification bar.
Recovering from a plugin crash is easy — simply reload the page. It would be nice to restart just the plugin without reloading the whole page, but scripts on the page won’t be expecting the crash, and can break or misbehave. It would be an interesting future experiment (addon?) to allow attempting to do this anyway, but for now reloading the page is a simple, conservatative approach that we know will always work.
You might have noticed that at the bottom of the placeholder UI there’s a message saying “A crash report was submitted.” Mozilla has an existing system for collecting Firefox crash reports, which are hugely useful for helping us detect and fix problems that users encounter. Plugin crashes are also able to generate these reports, and we can notify plugin vendors of their bugs. Crashes are annoying enough, so we decided that then was the wrong time to have annoying popups or checkboxes which require the user to make a decision about submitting a report. Instead, submission is controlled by a preference (exposed as a checkbox in the usual browser preferences window), and the browser will automatically submit the crash report when it’s enabled. The preference is shared with the existing Crash Reporter, so if you’ve previously told it to not submit crashes, that choice will continue to be honored (and, now you can disable submission without having to wait for a crash to happen — but we hope you won’t do this because these reports are so helpful for improving Firefox’s stability).
The visual style of this UI is also being used for what’s shown when a plugin is missing, disabled, or blocked. We’ve always had UI for those cases, but it was a bit barebones and ugly. Now it looks better, and further refinements are coming (see bug 545070).
If you’d like to check out this new UI, you’ll need to be running a current Windows or Linux trunk nightly. Sorry OS X, no OOPP for you yet. You can wait for a plugin to crash, or just kill it off from the OS’s task manager (look for a “mozilla-runtime” process).
Finally, here’s a particularly nice screenshot of how nice this UI can look in content. Thanks to Stephen Horlander for the beautiful visual design, and to Alexes Limi and Faaborg for UX. I think this will be the best crashed plugin experience you’ve ever had. (Oh, and don’t miss Sean Martell’s epic alternate version!)
Dolske's blog 
