575226 - flash / flex debugging is impossible with new hang detection feature

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[rgarcia.bilbomatica]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 (.NET CLR 3.5.30729)

This bug is related with Bug #574905, which is considered resolved.
The problem is right now it is impossible to debug a Flex application using firefox (as I have been doing for the last 18 months) as it is. This, I think, is still a bug. If someone is using flash player DEBUG version, it is expected that the execution of the plugin is interrupted. 
AFAIK, two solutions have been proposed:
1. Increasing the timeOut option
   - This is NOT a solution. It just lets you debug a few more seconds, and innecessarily delays the detection of real hang outs, freezing the whole browser until the time out.
2. Removing the timeOut option
   - This is HACK, not a solution. 
   - It is undocumented. Firefox does not offer a single clue about what can you do.

I understand the new feature is a good one. But right now, for us flex developers, it just broke Firefox. Last week, Firefox worked. Today, it doesn't. 

I'm using IE! Please fix this :)

Reproducible: Always

Steps to Reproduce:
1.Debug a flex application
2.Stop the execution on a breakpoint
3.Wait until the debugging session is interrupted and Firefox reports a Flash error, when in reality everything was going OK.

Comment 1

[Matthias Versen [:Matti]]

disable OOP for flash if you want to debug.
set "dom.ipc.plugins.enabled.npswf32.dll" to false.

I can't see a way to solve this without removing the hang detection feature

Comment 2

[Boris Zbarsky [:bzbarsky]]

> This is NOT a solution. It just lets you debug a few more seconds,

You can set the timeout to 100000 seconds, say...  At which point you will be exactly where you were last week.  Plugins will never get timed out.

Past that... are there solutions you'd like to propose?  What sort of workflow are you envisioning here?

Comment 3

[rgarcia.bilbomatica]

Thank you both for your answers.

- Matti, if removing the new feature is indeed the only way to solve this, I think it should be easy to do so. Having to browse through bugzilla and forums to solve this issue is just not reasonable. Why not put an option in the error screen to disable it?

- Boris, I did that last week and was debugging successfully. But see my previous point :) However, the biggest problem with this, as I said in the bug report, is the Firefox completely freezes when a flash error occurs. I had to kill the proccess, when before the error would appear in a window and Firefox would continue working without a flaw.

I don't mean to be ranting or anything. I just want to make clear my problem and make sure you understand it. So I'd like to be proactive in finding a solution.

- My first proposal as I said is to make it EASY to disable the feature. Most people won't bother with Firefox if it does not work for them. They will use IE or Chrome or whatever. I personally tried to find a solution but couldn't afford losing more time so finally decided to change browsers.

- A second solution would be to automatically disable the feature for DEBUG version of flash. As I said, if a program is debugging, it is expected the execution will be interrupted some time.

- Why not let the user decide if they want to stop the plugin? I know what I'm doing, it is terribly irritating that Firefox decides for me that my program's execution must be terminated. A button in a new toolbar (similar to the one to allow or deny pop ups) would be nice. But please do not interrupt the user's workflow.

What do you think? Thanks again for your time

Comment 4

[Boris Zbarsky [:bzbarsky]]

> when before the error would appear in a window

Before being before the preference change, or before 3.6.4 shipped?

> Why not let the user decide if they want to stop the plugin?

That's an excellent question, yes.  Benjamin?

Comment 5

[Benjamin Smedberg]

We decided that the UI which would be required (a modal dialog box disassociated from the plugin instance) would be more confusing than simply killing the plugin. We have documented the pref change required for flex debugging (set the timeout to -1 to disable it).

One possibility is to provide an API that Flash could use to disable the hang detector, but we really don't want to do that either, for fear that the API would be misused by plugin vendors trying to making hanging a normal activity.

Comment 6

[rgarcia.bilbomatica]

Benjamin,
- How about my suggestion to use the same interface that you use to Allow/Deny pop ups?
- Could you please let me know where is this documented?
- In what way including some information and help to disable the option after killing the plugin would make the interface more confusing?
- I agree with you in the last point, it does not have to be that complex.

Thank you

Comment 7

[rgarcia.bilbomatica]

I see it is documented here:
http://support.mozilla.com/en-US/kb/The+Adobe+Flash+plugin+has+crashed

However, I really think at a least a link should be included with the error. Why making the user lose time searching for a solution when you there is one?

Comment 8

[Benjamin Smedberg]

There *is* a help link from the error... it currently goes to http://support.mozilla.com/en-US/kb/Plugin+crash+reports?style_mode=inproduct&as=u

We should probably get that hooked up to information about disabling the hang detector.

Comment 9

[Ricardo Maçãs [:Ricmacas]]

http://support.mozilla.com/en-US/kb/The+Adobe+Flash+plugin+has+crashed
The link states the solution for this problem, which is a specific case of a plugin hang. We could put a note there about Flash/Flex debugging, but it might confuse users who have no idea what is "flex" or "debugging" (We at SUMO have been putting a lot of effort into simplifying articles).

Either way, the default link points to http://support.mozilla.com/en-US/kb/Plugin+crash+reports?style_mode=inproduct&as=u , which is a generalist article about crashes of plugins. I'm not sure if this was considered (maybe someone thought it was unnecessary), but if link changed according to the plugin, then it would be easier to troubleshoot this problem. There's a link to flash crashes in that article, that points back to the article i mentioned in the paragraph above.

We haven't yet updated our articles to reflect the Beta 1 of Firefox 4 which includes OOPP (3.6.6 does not).

Comment 10

[Ricardo Maçãs [:Ricmacas]]

Ugh, I meant 3.6.6 doesnt include OOPP on MAC.

Comment 11

[rgarcia.bilbomatica]

I see http://support.mozilla.com/en-US/kb/Plugin+crash+reports?style_mode=inproduct&as=u now includes help about this issue.

This is a big step forward in my opinion. Thank you

Comment 12

[Ricardo Maçãs [:Ricmacas]]

There's a specific note now, but if you click the link presented in the article, it points back into the - already existing - proposed solution for general flash crashes :) .