Crashed Plugin UI

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!)

24 thoughts on “Crashed Plugin UI”

  1. It would be nice if it was clearer that Flash crashing isn’t Firefox’s fault, so that users won’t think “stupid Firefox”.

  2. Just to clarify, this could be done by changing the message like this:

    “The Shockwave Flash plugin has crashed. This plugin is not part of Firefox and is out of Firefox’s control. Reload the page to try again.”

    I’m not sure if that’s quite the best wording, but it communicates my intention.

  3. Perhaps the reload icon could also be included to help people who may be confused about what action should be taken.

  4. I can’t find the preference about crashes submissions exposed as a check box in the usual browser preferences window.
    Could you please tell me where can I find it (under which Preference window tab?
    I would really appreciate it!
    Many thanks!

  5. “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.”

    So if it crashes on one page, I’d have to restart all the pages with that plugin as well, right?

  6. Yeah, you’d have to restart everything. Turns out Flash at least relies on plugin instances sharing the same address space, even if NPAPI (from what I understand) never said anything about the issue (somewhat unsurprisingly, it’s not like browsers seriously considered doing anything out of process in the first decade of their existence or anything).

  7. Is OOPP going to have any impact on CPU usage? (It matters when trying to play back HD Flash videos on older hardware.)

  8. dolske: can we ship or link to the logos of the primary plugin vendors, and give them some much-needed brand exposure in this dialog?

    I’m dead serious. If the Flash (and Adobe?) logo came up every time Flash crashed, this would start turning into a seriously negative PR event for them. Think how many Flash crashes there are per day! And that can only encourage them to get their act together.


  9. Any plan to link this to plugin check? Some of the crashes are due to old versions of the plugin, would be nice to tell users “Are you sure you’re running the most up to date version of this plugin?”

  10. Gabriela:

    The pref is currently at the bottom of Prefs -> Advanced -> General (it’s possible it will move if we find a better spot for it).

    Zil: AFAIK, I wouldn’t expect it to change CPU in any significant way. It’s the same plugin code, so if Flash has problems decoding HD video on slow hardware, it being in-process or out-of-process doesn’t really matter.

    Gerv: If you can work out the logo-usage contracts, we would probably look at it! πŸ˜‰

    Marco: Hmm, that’s an interesting idea. We do already have a “outdated plugin” warning (notification bar) that can be shown in such cases (or block the plugin entirely, if it’s a security risk). And the crash report text in the UI links to SUMO, where we could say something about that. But maybe having a way to say something directly in this UI when we know it’s a problem would be good to have.

  11. It’s probably not only the decoding of videos that’s expensive computationally, as covering the display area with another window makes the CPU usage drop significantly. I was just wondering if this affects how quickly Firefox can display the sequence of images, or if transferring all that data between different processes is any slower than transferring it within the same process.

  12. Justin Dolske:
    Yes, I’ve found it now just where you’ve told me, many thanks for doing so! It wasn’t there when I submitted my question though!

  13. hey i’m using linux amd64 and the official 64 bit version of firefox from but i cannot see the message, the embedded plugin just disappears though i kill the mozilla-runtime process
    is this not yet implemented on 64 bit or linux or is there another problem (bug)?

  14. Dolske: we wouldn’t need logo usage contracts IMO; it would be fair use. Check with Harvey, but I think it would be OK.


  15. Is it possible to reload the plugin without having to reload the page? Also maybe place a link to the home page of the plugin, this would make it more obvious it’s their problem and not Mozilla’s.

  16. All flattering granted to everybody who is keen on it, but OOPP was by far the WORST that could happen to Mozilla!
    I have always been an eager nightly build tester…more than a year! Reported bugs, seen them fixed etc.
    But you guys have now lost a long-term nightly tester in ME. I won’t support this any longer: Mozilla has given up all stability concerns even (!!) in nightly builds, which are deemed to be unstable but were NOT! All perfect before the OOPP bullshit came along…now I have Flash crashes in every 2nd youtube video, and I won’t accept that at all.
    Mozilla, 2009 was a fantastic year. Thank you. And good-bye – for good.

  17. @Gerv:

    Why not expand the Plugin API so vendors can add logos to the plugins? This would also benefit the Add-ons Manager!

Comments are closed.