> time and bandwidth for both the user and site (due to the following comment) > to manually refresh each and every single tab. > number of tabs that had the crashed plugin loaded. > I just think it would be annoying to dismiss the notification bar N times for N > but for sites that don't have the plugins autoplay, this makes sense. > of them to watch one at a time now having all tabs videos start playing again > users who may have opened a dozen tabs of youtube videos and paused all but one > That is what I would personally like but then again we'd run into the issue of Bug 391725 should be WONTFIXed then even though I disagree. Make a little sense to me even though I don't understand exactly what you mean but I get the jist of it. > about the plugin state which will no longer be correct. > We don't want to refresh in-place because page script often makes assumptions Just for conversation sake here, what does chrome do? This is turn wastes the users time and bandwidth for both the user and site (due to the following comment) just because the page would need to be manually refreshed when we technically don't have to. The users would then have to manually refresh each and every single tab. I just think it would be annoying to dismiss the notification bar N times for N number of tabs that had the crashed plugin loaded. That is what I would personally like but then again we'd run into the issue of users who may have opened a dozen tabs of youtube videos and paused all but one of them to watch one at a time now having all tabs videos start playing again but for sites that don't have the plugins autoplay, this makes sense. > Kurt, what would the effect of dismissing that notification be? to refresh all Note that bug 525849 covers UI for submitting crash reports for the crashed plugin. If not, we should drop down the doorhanger. * If the plugin notification can be displayed directly within the plugin frame, ** is the plugin large enough to display a notification directly within it * Any subsequent times the plugin crashes, we should check to see

* If the user reloads in any way (doorhanger, toolbar, or Ctrl-R), we should * The doorhanger should have a checkbox, on by default, for submitting theĬrash report, and a text, something like 'Adobe Flash has crashed.' and a * The first time a plugin crashes, we should drop down a doorhanger. As such, we need to add browser and content UI to handle when this happens so the user knows what's going on.įrom bug 519541 comment 5 - limi made some preliminary suggestions for what this UI should be: With out-of-process-plugins, plugins can now crash without taking down the entire browser. This prevents Firefox to mistakenly assume that EPPI-Reviewer 4 has stopped responding (usually happens when waiting for the user to click on a dialog box) and subsequently shutting down the application.+++ This bug was initially created as a clone of Bug #519541 +++ The drawback of this approach is that if a plug-in genuinely crashes, the crash will propagate to Firefox itself on the other hand, with the protection turned on a crash only affects the web pages that use the crashing plug-in.Īlternatively, to remove the main source of trouble within EPPI-Reviewer, but keep Firefox Crash protection active, you may:ģ.Set the value of to -1 This will disable the infamous crash protection for all plug-ins, including Adobe Flash. That’s it, 'plugin–container/crash protection' is disabled. It's all or nothing now, I'm afraid.ġ.Type about:config in the URL box and, if necessary, click 'I’ll be careful, I promise'ģ.Double click on to set the value to false.Ĥ.Restart Firefox.

Apparently Mozilla has removed the ability to disable the crash protection for Silverlight only.

Firefox adobe plugin has crashed