345454 - The Unresponsive script dialog may get under the main window

Status: RESOLVED INCOMPLETE

(Firefox :: General, defect)

Description

[Michal 'hramrach' Suchanek]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

When the system is under load aand Firefox is running it produces a bunch of Unresponsive script dialogs. These dialogs are not visible but prevent most controls in the main window from functioning.



Reproducible: Sometimes

Steps to Reproduce:
1. Run firefox
2. log into gmail (or load another page using JS refreses)
3. start some software that requires lots of memory/cpu time (ie compile something)

Actual Results:  
firefox produces several Unresponsive script popups, and they are not visible

Expected Results:  
firefox does not produce popups when it is not the script what caueses the slowdown

the popups should be visible

workaround: the popups can be selected using the window menu, they appear as empty lines (windows without title)

Comment 1

[Anders Conbere]

- First issue regarding not throwing the dialog -

So what firefox does here is it has a maximum alotted run time of 5 seconds for any JS script.  This is because the chrome parsing and the page parsing of js happen in the same thread.  This means that a script that is left running renders the ui completely unresponsive.  This is considered "very bad" and I agree.  The problem in this case is obviously that if you're taxing your system resources scripts may take longer to execute than would otherwiser be expected, however firefox has no way of knowing that it's you compiling that's causing this, firefox just knows that it took over 5 seconds to execute.

- Second Issue regarding dialogs being hidden -

WFM, I haven't seen any of them raised under the main window, if this is a real concern it should be filed in a seperate bug.

Comment 2

[Michal 'hramrach' Suchanek]

yes, the real concern here is that the dialogs do get under the main window.

Perhaps it is necessary to get several of them or to get them while firefox is not the active application, and select Firefox by clicking the main window (which could raise it above the dialogs).

Comment 3

[Michal 'hramrach' Suchanek]

I tried to reproduce this again. When several "unresponsive script" dialogs are displayed at once only one is on top of the main window, the others are not visible, and they aren't shown when the visible one is closed. 

Comment 4

[Anders Conbere]

do you think you could build a test case? (several js scripts that wait for a specified period of time should do it).

Comment 5

[Michal 'hramrach' Suchanek]

I do not know how to make a script wait. Sorry.

Comment 6

[Michal 'hramrach' Suchanek]

I cannot even reproduce it with two simple tight loops in separate <script> tags (this is not a testcase because the loop length would be probably system specific). The second is only executed after the dialog of the first is closed. The same for onLoad.

It is probably necessary to use some timer to execute the script while the dialog is open.

Comment 7

[Roman R.]

I just had this problem and lost data because of this. Running Firefox 2.0.0.7.

Apparently, this happens on Windows (Vista) too. However can, please change the OS field to reflect this.

Comment 8

[Roman R.]

"the chrome parsing and the page parsing of js happen in the same thread."

Really? I made a similar mistake when I was learning programming. I wish that more thought would go into developing this browser.

Comment 9

[Michal 'hramrach' Suchanek]

changing to OS:All based on comment #7

Note I can no longer easily test this, this requires a relatively slow or overloaded system unless a special testcase is developed.
The dialog no longer appears for me on the system I currently use (Linux), and the issue never happens there (probably because I use a special window manager that always puts modal dialogs above and splits other dialog separately so I am always aware of any open dialogs).

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Clearing blocking request, please feel free to renominate if this bug is confirmed.

Comment 11

[Wayne Mery (:wsmwk)]

seeing this today - script message behind other windows.  This is not new, nor is a secondary issue 
 - no buttons to click in the "Warning: Unresponsive script (Not Responding)" window

But this I have never seen:
- per task manager application tab, SOME FF windows (about half) are "Not Responding" and half are "Running" - that's just weird - and indeed half of my 41 FF windows are unresponsive.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Comment 12

[(mostly gone) XtC4UaLL [:xtc4uall]]

Has anyone seen this Issue on a more recent Firefox Version?

Comment 13

[Mark Brighton]

I have a consistent problem with this on Mac OS X 10.6.4, Firefox 3.6.10, and the Firefox PDF Plugin for Mac OS X 1.1.3.  

When saving a PDF, the unresponsive script dialog will appear below the save dialog.  The save dialog buttons become non-responsive and it is not possible to bring the unresponsive script dialog to the forefront.  I have not found a way to get out of this situation besides forcing quitting the app.  

Firefox thinks the script is unresponsive, but in reality it is waiting for the (relatively) slow human input.  I don't know if this is an issue with the Firefox feature or if the script should be indicating that it is waiting on user input and is not.  

This has been submitted to the plugin project as issue 170 (http://code.google.com/p/firefox-mac-pdf/issues/detail?id=170).

Comment 14

[Wayne Mery (:wsmwk)]

Roman, Michal, can you still reproduce?

Mark, on current versions of firefox the (Mac) hang is bug 476541.
The original issue of this bug is something less severe.

Comment 15

[Michal 'hramrach' Suchanek]

The root issue here is that Firefox needs to manage its windows when it is showing a modal dialog.

When a user action is blocked by a dialog that dialog must be focused and brought to front.

This is a problem with cookie dialogs on Linux (which are not dependent on system performance and multiple can appear on sites that load multiple resources that send a cookie).

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Iceweasel/3.6.13 (like Firefox/3.6.13)

Comment 16

[Roman R.]

I haven't observed this for a long time.