569493 - Firefox 3.6.4 Crash Report [@ hang | NPSWF32.dll@0x3184d7 ] - [@ hang | NPSWF32.dll@0xf1fa1 ]

Status: RESOLVED WONTFIX

(External Software Affecting Firefox Graveyard :: Flash (Adobe), defect)

Description

[Carsten Book [:Tomcat]]

Steps to reproduce: (XP, 1.9.2 Debug Build)
-> Load http://garlstedt.myminicity.es/
-> After a few seconds you should see the plugin crahs information

http://crash-stats.mozilla.com/report/index/bp-fbfd3b17-6aa0-40fc-a83f-07f322100601

Also on 1.9.1 Builds this site triggers a slow script warning for flash

Comment 1

[Charles]

I get the slow script warning but not a crash.  Slow script dialogs are put in place to keep people from coding infinite loops and hanging the process.

Comment 2

[chris hofmann]

so with OOPP in firefox 3.6.4 will users ever get to the flash slow script warning?  guessing the firefox will now kill off the the plugin that appears to not be responding, so users will never get to the slow script warning any more where OOPP is turned on.

it would be interesting to know what the time out period for the slow script warning is on the flash side, and how this maps to the time out of the hang detector on the firefox side.  It looks like it might be 12-16 seconds after the initial page load, and then again after each user selection of "let the script run"  

I'm guessing that there is no way for flash inform the browser that the user wants to let the script keep trying to run if we did ever make it to the slow script dialog.

Comment 3

[Benjamin Smedberg]

Indeed, this is us being a little more aggressive in our timeout than Flash is. And I do not want to accept a plugin API which would let the plugin override the hang detector (it was proposed and rejected in Chrome as well).

Comment 4

[chris hofmann]

are the hang detector timeouts on flash or firefox configurable via a pref?  

I wonder what happens if the flash detector is set to throw the dialog just before the firefox hang detector fires?   that might create a condition where the plugin will always look like its responsive when the fx hang detector fires, and allow the user to stay in control of this situation.  this mostly might be useful for developers that are developing and debugging non-optimized applications.

sounds like this bug is WONTFIX for general users and will remain a good test case for making sure hang detection and kill with OOPP is working as expected.

Comment 5

[Benjamin Smedberg]

It is possible to disable the Firefox hang detector or change the timeout using dom.ipc.plugins.timeoutSecs (-1 to disable).

Comment 6

[chris hofmann]

we might want to grab the content and throw it in the test suite somewhere. with the expected result is that this page forces the plugin crash and reload.

Comment 7

[Benjamin Smedberg]

We already have automated tests for the hang detector, and we cannot use automated tests with Flash because we cannot redistribute it with the test package.

Comment 8

[chris hofmann]

the suggestion in comment 4 about allowing the flash timeout to happen first doesn't work.  

I set  dom.ipc.plugins.timeoutSecs=16
loaded the page
flash unresponsive dialog pops
then browser window pops back on top to inform that the plugin has crashed

at that point the browser becomes unresponsive (maybe due to a flash modal dialog that can't be reached?)

the only solution at this point is to kill the browser with the task manager.

Comment 9

[chris hofmann]

note to self, or maybe a source comment:

if we ever advance pref("dom.ipc.plugins.timeoutSecs", to something greater than the flash slow script time out,  or the make a change on the flash side to speed up the time out notification it will create a world of hurt for firefox users....

Comment 10

[Benjamin Smedberg]

Please file comment 8 separately, that's something we can/should fix, I think.

Comment 11

[chris hofmann]

Filed Bug 570249

Comment 12

[Carsten Book [:Tomcat]]

Hey Guys i think this Bug got merged into something not expected :) I think its not wontfix, because http://garlstedt.myminicity.es/ still cause a error also with the flash rc 7 


Build: Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6pre) Gecko/20100604 Firefox/3.6.6pre

CrashReport: http://crash-stats.mozilla.com/report/index/bp-b3a29fd7-5e7d-4926-aee6-44ee92100604

I mentioned this slow script only as the report for 3.5 Branch. But overall the Problem still exists :) thats why i filed this in the abobe flash component

Comment 13

[Benjamin Smedberg]

Tomcat, what part is different? The flash script is taking a long time. Pre-OOPP Flash will display the slow script dialog. Post-OOPP Firefox will kill the Flash script. We have a bug tracking the problem, and we've decided that this is the correct (intended) behavior, thus WONTFIX.

Or am I missing something?

Comment 14

[BMO Automation]

Version and milestone values are being reset to defaults as part of product refactoring.