Created attachment 454218 [details] [diff] [review] Patch v.1 +++ This bug was initially created as a clone of Bug #560932 +++ Over if bug 560932 we discussed increasing the "hung plugin" timeout, but ultimately decided to leave it set at 10 seconds, as the value of OOPP is decreased if it takes painfully long to kill a hung plugin. However, now that 3.6.4 has shipped, we are seeing an increasing number of reports that some users are unable to play Farmville, because Farmville hangs the browser long enough for out timeout to trigger and kill it. As an interm solution, we can increase the timeout and then look for a better solution. The SUMO article suggests that 30 seconds is a good value, so let's hit this with a big hammer and make it 45s.
What about the situation has changed since the first time? Don't we think that users would notice if Firefox were unresponsive for 20, or 30, or 45 seconds? It's possible that the Flash app is still responsive, if it's in windowed mode: it's also possible that it can still do animation and audio even when it's not responsive. But I think we have a problem where OOPP is allowing Flash to eat a lot more CPU than it used to, and changing the timeout is a really unfortunate tradeoff. That said, I don't know how we can diagnose the Flash-consuming-CPU thing. Maybe we need some tbeachball-ish numbers IPP and OOPP (OOPP need beachball numbers for both processes).
My (second-hand) information is that we're seeing a significant volume of support requests for the issue, whereas the scope of the problem wasn't clear before. The SUMO article recommends increasing the timeout to 30 seconds, which I assume has been found to work by users experiencing this problem (Cww, can you confirm?). http://support.mozilla.com/en-US/kb/The+Adobe+Flash+plugin+has+crashed So this is the small+simple fix suitable for a rapid chemspill release, shaver asked me to generate the patch ASAP. Does it seem sensible to land this now for the chemspill, and look at a better way to fix the problem for the next 3.6.x release?
Users would notice, and they do with Farmville per their support, but then it finishes initialization and they're happily on their way. They're fine with it taking a while to start up their game (many games take more than 10s to load outside of the browser!) and aren't trying to do other things with their browser in parallel. Why do we think that this is related to elevated CPU consumption?
In all of the (two) cases I've been able to catch so far (which usually involves hulu + farmville or similar windowless cases), Flash is spinning its event loop pretty regularly, but the event loop is so backed up that we don't get around to begin delivering our message until the timeout has expired.
I don't understand why we would start timing before we deliver the message whose reply we're waiting for, but I am merely a simple caveman. I *do* understand that there's a massive regression in user experience for a meaningful number of users of an extremely popular property, and that a raised timeout remedies it. We can and should investigate better event loop behaviour, perhaps even for the next non-chemspill release, but for now we need to get out of a bad hole before it gets any worse.
GECKO1924_20100413_RELBRANCH: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/d58a3937538c 1.9.2 default: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/fcc48654336d
Status: NEW → ASSIGNED
status1.9.2: --- → .6-fixed
When a plugin is really slow in Google Chrome, I get a dialog with the option to close the plugin or continue.
My $0.02 Originally a 10s timeout made a lot of sense considering that we had no actual data to go with. AFAIK that number didn't come from the mountain top on a stone tablet. Now that we have information that it's prematurely killing working plug-ins, it's obviously time to re-evaluate. We have to increase the timeout value. My preference would be to go with 30s and wait for feedback. But whatever value with try next, once we have real information that the timeout is too long we will again need to re-evaluate.
Pushed to trunk: http://hg.mozilla.org/mozilla-central/rev/18c4baeeba95
Status: ASSIGNED → RESOLVED
blocking1.9.2: .6+ → ?
Last Resolved: 9 years ago
status1.9.2: .6-fixed → ---
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a6
blocking1.9.2: ? → ---
status1.9.2: --- → .6-fixed
This goes way beyond my understanding of IPC, but is there really nothing that the browser can do or say whilst a plugin is hanging? Some indication that waiting for the timeout will bring the browser back to life would be good, rather than the user clicking a few times until he decides to (or the OS offers to) kill it.
I can't believe Farmville is solely responsible for a Firefox update *facepalm*
Using the priority idea from https://bugzilla.mozilla.org/show_bug.cgi?id=558555 maybe could allow to make detection more reliable. I'd hate to have to wait 45 seconds until I can use firefox again. Most users will probably assume it crashed during that time and kill it.
(In reply to comment #11) > I can't believe Farmville is solely responsible for a Firefox update *facepalm* It wasn't just happening in Farmville.
(In reply to comment #11) > I can't believe Farmville is solely responsible for a Firefox update *facepalm* Actually, I think this could be a good example of how a change to the impact of a problem can push it to the top of the queue. A lot of people play Farmville. To ignore those people for any length of time could have a significant effect on Firefox's share of browser users. The problem already existed, but the perceived impact suddenly changed, giving it a much higher priority. http://www.knowledgetransfer.net/dictionary/ITIL/en/Impact.htm
(In reply to comment #13) > (In reply to comment #11) > > I can't believe Farmville is solely responsible for a Firefox update *facepalm* > > It wasn't just happening in Farmville. it's happening to people like me actually doing some work on my not so old machine like compiling in a bunch of vm's while browsing. In my case it's not a case of single/dual core cpu but one of a very busy harddisk.
I'm a flex developer and I use Flex builder to debug flash programs. In previous Firefox versions when I run the Flex builder debugger to debug through a flash plug-in it doesn't have the timeout problem. Now with this release 3.6.6, all of a sudden when I stop at a breakpoint insided the Flex debugger, after some seconds (45 according to the description?) the Flash plug-in just reports a "crash" and thus disconnects the Flex debugging session. This is detrimental to my development. Is there a way to revert back to previous version or turn off this timer to not allow a timeout? Thanks
(In reply to comment #16) > I'm a flex developer and I use Flex builder to debug flash programs. In > previous Firefox versions when I run the Flex builder debugger to debug through > a flash plug-in it doesn't have the timeout problem. Now with this release > 3.6.6, all of a sudden when I stop at a breakpoint insided the Flex debugger, > after some seconds (45 according to the description?) the Flash plug-in just > reports a "crash" and thus disconnects the Flex debugging session. This is > detrimental to my development. Is there a way to revert back to previous > version or turn off this timer to not allow a timeout? Thanks If it is for your own version you can set the dom.ipc.plugins.timeoutSecs key to any value you want in your about:config.
(In reply to comment #17) > If it is for your own version you can set the dom.ipc.plugins.timeoutSecs key > to any value you want in your about:config. As an Addition: Setting dom.ipc.plugins.timeoutSecs to -1 disables the Hang Detector. Further Questions should be directed to https://support.mozilla.com as this is a Bugtracker and not a Forum. Else you're free to file a new Bugreport.
Do all the calls into plug-in have to be synchronous? Some plug-in calls (like NPP_SetWindow/HandleEvent) do not seem to return any important value (except some error) so why we need to wait when they're finished?
Has anyone tested that this is not a new problem from Flash 10.1? I have noticed that Flash 10.1 performs about half as good as Flash 10 in plugin based browsers, vs. IE (30fps on the linked example, vs. 60 in IE). Before spending too much time adding a workaround for this in Firefox, you may want to look into that. Suggestion: downgrade to Flash 10 (mind the security hole) and test. Then upgrade to Flash 10.1 and retest. Note the issue I've been seeing is on Windows - on Mac Flash 10.1 runs great in Firefox, but lousy in everything else. You can check that with this example if that helps (it's my blog, but I don't have any ads): http://www.unfocus.com/2010/06/23/the-pixels-explode-explode/ direct link to the swf (if it's useful, please feel free to add it to the ticket): http://www.unfocus.com/PixelExploder/Explode.swf
I agree with comment #23. I think the hang crashes are more of a Flash bug than a Firefox bug. I've noticed Flash 10.1 has severely degraded performance so the majority of the problems probably had less to do with the Flash hang detection and more to do with people upgrading to Flash 10.1 As an example, Hulu now takes a minute to load videos with Flash 10.1 and uses a whopping 1 GB of memory compared with 256 MB with Flash 10. Even increase the timeout to 45 seconds doesn't always allow Hulu videos to load.
(In reply to comment #18) > (In reply to comment #17) > > If it is for your own version you can set the dom.ipc.plugins.timeoutSecs key > > to any value you want in your about:config. > > As an Addition: Setting dom.ipc.plugins.timeoutSecs to -1 disables the Hang > Detector. > > Further Questions should be directed to https://support.mozilla.com as this is > a Bugtracker and not a Forum. Else you're free to file a new Bugreport. This solution works great for my purpose. Thanks
Verified interval change to 45 on 3.6.6
Status: RESOLVED → VERIFIED
Verified also on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:126.96.36.199pre) Gecko/20100630 Namoroka/3.6.7pre and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52pre) Gecko/20100630 Namoroka/3.6.7pre (.NET CLR 3.5.30729)
I don't know if anyone is following what's happening on the support forum: https://support.mozilla.com/en-US/forum/1/710861#threadId715141 Maybe this is not such a good fix...
As a result of this plugin handling, it has created #574905
I'm a retard. See #577656
Please re-open as I am still getting premature timeouts, and FF says something like ... did not respond ... I am on FF firefox-3.6.10-1.fc13.i686 There is another reason why this timeout should be user settable in Preferences. I run a firewall which dumps packets that are not part of an ESTABLISHED session that was established by FF, for example. So, when FF times out prematurely relative to the speed of a web sites response time, the response packet arrives, and since the session was terminated by FF, the firewall dumps the packet as unsolicited incoming packet. My log shows hundreds of such dumped packets from slow web sites. Please reopen this bug and allow the user to adjust timeout in Preferences, according to user's needs.
JD: this is a bug about plugins hanging, and not related to the problem you're describing.
In that case, should I open a new bug?
You need to log in before you can comment on or make changes to this bug.