Closed Bug 476541 Opened 15 years ago Closed 1 year ago

[non-e10s] Hang if page puts up an alert sheet while a modal dialog is open [Mac]

Categories

(Core :: Widget: Cocoa, defect, P3)

Product:
Core
Component:
Widget: Cocoa
Platform:
x86
macOS
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: whimboo, Unassigned)

References

(Blocks 2 open bugs,
URL
)

Details

(Keywords: hang, testcase, Whiteboard: [tbwants][tpi:+][tpi-help-requested])

Attachments

(6 files)

image of two blocked dialog boxes
(deleted), image/gif
Details
The "Save As" dialogue is interrupted by a Gmail calendar reminder.
(deleted), image/png
Details
The same problem occurs in Thunderbird, if this alert (GnuPG not found, see image) pops up while in a "save as..." dialog.
(deleted), image/png
Details
Unresponsive Script Dialog Box
(deleted), image/gif
Details
"Unresponsive Script" dialog can't be dismissed and Open File can't Cancel or Save
(deleted), image/png
Details
With an unresponsive script dialog active, neither that dialog nor Open File can be dismissed
(deleted), image/png
Details 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090202 Minefield/3.2a1pre ID:20090202020617

+++ This bug was initially created as a clone of Bug #468393 +++

Following the steps will hang the browser completely:
1) Load https://bugzilla.mozilla.org/attachment.cgi?id=351645
2) Hit Cmd+S before the alert comes up
3) Wait...

While staying in step 3 you will see that the alert sheet is positioned under the save dialog. When this happens there is no way to close the save dialog. The browser has to be killed.

See also attachment 352138 [details] for a stack trace.
Flags: blocking1.9.1?
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Do we really want this bug to block the 1.9.1 release?

As I mentioned above, there's already a patch for this bug at bug
468393 comment #24.  I think the patch is perfectly adequate (as
something to tide us over until larger changes are made to Gecko and
Cocoa widgets to allow modal windows to work properly on OS X).  But
Josh disagrees, and has rejected the patch.

Even I say that my patch is speculative enough that it must go into a
beta (not an RC) -- so it would need to block beta3.  And there's no
chance I'll be able to come up with a better patch before we re-write
the modal windows implementation on OS X.
This bug is bad but not a regression, I believe any patch would be too risky for 1.9.1. We need to fix this class of bugs the right way and we're looking into it for 1.9.2.
Flags: blocking1.9.1+ → blocking1.9.1-
Assignee: joshmoz → nobody
Blocks: 482811
Attached image image of two blocked dialog boxes (deleted) — 
Hi,

Just thought I could add my experience with this problem.

I'm using Firefox 3.5.2 on Mac OS X 10.5.8 and I also had this problem a couple of times, also with earlier releases, but I could not precise exactly since when.

It seems to me that force quit is the only option whenever two dialog boxes appear at the same time, no matter if they are "script no responsive", "print/save as pdf dialog", "accept cookies?" or "type your master password".

It seems like the bugs linked down under also reflects this problem (duplicate?):
https://bugzilla.mozilla.org/show_bug.cgi?id=509709
https://bugzilla.mozilla.org/show_bug.cgi?id=488079

I am attaching an image of the blocked dialog boxes
Flags: wanted1.9.2?
Summary: Hang if page puts up an alert sheet while the save dialog is open → Hang if page puts up an alert sheet while a modal dialog is open
Perhaps Bug 479749 is a duplicate as well?
(In reply to comment #12)
> Perhaps Bug 479749 is a duplicate as well?

Sorry - that bug # was a typo - I'd intended to mention Bug 479743 as a potential duplicate.
(In reply to comment #13)

It might be, but there's not enough information at bug 479473 to tell.
Whiteboard: [tb3wants]
Whiteboard: [tb3wants] → [tb31wants]
I was confronted with this bug three times today by just switching away to another application while the save dialog is open. Coming back after around 10-15s I always see the script alert dialog which blocks everything. You have to hard-kill Firefox.
blocking2.0: --- → ?
I can also reproduce this with this url:

data:text/html,<iframe src="javascript:print()"></iframe><iframe src="javascript:alert(0)"></iframe>
Is is getting very annoying in the last weeks. All the time when you have open the save as dialog and switch to another application, the script alert dialog pops-up and blocks the whole UI. I have to run a force kill on Namoroka. :/

Steps:
1. Open a web page and press Cmd/Ctrl+S
2. Switch to another application
3. Wait some seconds

It would be fantastic if we would find some time to fix it for Firefox 3.7.
Josh, would you make a blocking call on this?
How far did we get with the 1.9.2 work described in comment 3?
We didn't get started on fixing the major modal dialog bugs for 1.9.2. I'd really like to fix this for 1.9.3 but I don't think anything has changed when it comes to blocking a release (we minused it for 1.9.1 and 1.9.2). I'll look in to when we might be able to do this again.
blocking2.0: ? → -
This is looking to be a bit more common than you'd imagine.  Dave found it this morning because Firebug caused a "slow script dialog" while he was trying to print something, and he was using 3.6.3 released builds.  I had it just happen to me on a lanikai nightly when another extension caused a slow script dialog while I had open an "attach file" dialog to attach something to an email message.  

Since for our future releases we are actively pushing extensions, jetpacks, and putting weave into Firefox, I think that we are potentially creating a scenario where it is more likely end users will hit this bug.  And I think that the "work around" (i.e. force quit the application and restart) is severe enough that we should fix this sooner rather than later.  In short, please find a way to block 1.9.3 on this.
This problem occurs in both, Firefox and Thunderbird.
I always get this with the "Save As ..." dialog on a image when i'm not fast enough.

To reproduce, open the save dialog (with "Save As ..." on a image in the page) and then wait a while (like around 20 secs) you get a dialog saying that a script has hanged on the page, and the script is 

/Applications/Firefox.app/Contents/MacOS/modules/NetworkPrioritizer.js 

and you end up in the situation described above being unable to dismiss both dialogs.

I had this happen since 3.5 and on OS X 10.5 and 10.6.  I do not remember this happening with 3.0 but I cannot comfirm the bug was not present.
Apparently, in some instances having the Save As... dialog open produces the "Script unresponsive" sheet even when the page has no script.  I was able to reproduce this reliably by:

(1) Go to the URL of a .jpg image.

(2) Type Cmd-I to bring up the Get-Info window

(3) Go to the Media tab

(4) Click the Save-As button to bring up the Save-As dialog.

(5) Switch to another application, wait 30 seconds, and switch back to Firefox.

The Get-Info window will pop up the unresponsive-script sheet, and neither the sheet nor the Save-As dialog can be dismissed--the only solution is to force quit.

It looks as if the presentation of the Save-As dialog is causing the responsiveness-checker to fail to get its expected response, so if you delay too long at Save-As it will think there's a script problem even when there is no script on the page.
What I can guess is that there are scripts in other places too, non only in shown pages (eg.: the Stylish plug-in).
Add me to the list.  I'm getting this too.  It's easy to reproduce. I just try to print a webpage and then use the "Save as PDF" option.  It usually happens when I'm trying to fill in the PDF information like filename, title, subject, keywords, etc.  It usually takes me a while to get that all filled in.  That's when I get the "Warning: Unresponsive script" dialog box.  It says: A script on this page may be busy, or it may have stopped responding. You can stop the script now or you can continue to see if the script will complete. Script: chrome://noscript/content/ClearClickHandler.js:182"

I'm not sure why it says "chrome:..."  I have chrome installed, but I'm running Firefox. Hmm.  Anyway, I have a picture of the dialog box if you want it.
Attached image Unresponsive Script Dialog Box (deleted) — 
This is a screen capture of the dialog box that comes up while I'm trying to fill in the "Save to a PDF" print dialog box.
This also happens if an add-on/extension puts up a dialog box and the user takes too long (either selecting options or entering information in the dialog box) before the dialog box is dismissed.
The trouble also appears when an error occured while downloading: a sheet window appears IN the Download window telling the user that Firefox is unable to download file xxx (either a downloaded item _and_ an item that is part of a web page).

It is not only a "Warning: Unresponsive script" bug.

At last, FireFox version 3.6.8 is the current version.
Would it be at all possible, if this gets fixed in time, to apply it to Firefox 3.6.x as well, since it is the last PowerMac branch? Those of us who cannot afford to upgrade our ancient hardware would appreciate the fix, even if it's the last Firefox build we see before we can upgrade.
No one assigned to fix this?  How can that be induced?
I can assign it to you if you'd like.

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
1. No pointless comments. 
2. No obligation.
Why not a bidding system?   People could vote wish cash commitment.  This is a serious bug, but there is no one responsible to fix it so offer cash as inducement.
that's offtopic. try google? http://forums.mozillazine.org/viewtopic.php?t=100594
Ran into this bug again today while saving a PDF document, my AT&T session logged me out and threw up a modal dialog to tell me.  Can't complete the Save As.. or get to the modal to acknowledge it.

Mac OS X 10.6.4
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100722 YFF35 Firefox/3.6.8 GTB7.1
OS: Mac OS X → Windows XP
I assume that change to Windows XP wasn't intentional, since Windows doesn't have Widget:Cocoa...
OS: Windows XP → Mac OS X
Mac OS X has increases its piece of the OS pie materially, yet no one in the developer group sees this.   Is the model broken?  Bounty system if bugs are looked at those critters? Timeless?
Mac OS X 10.6.4; Firefox 3.6.10 
I navigated away from the print dialog box for a while then came back to this bug.  Had to force quit.  (The good news is the e-commerce confirmation page I was on redisplayed on re-launch and I was then able to print it.)

Posting to be added to cc list
This bug is really frustrating -
Again every time I try to do a pdf print, there is a dialog box is shown and even I can follow all the pdf printing step, but :
1- the pdf file is never been saved
2- everything else is hanging, FF can be quit (even "Quit" mode is shown), none of the windows/tab can be closed, basically nothing can be done.
3- the only way getting out of this problem is do "Force Quit" from apple option
and that means all my FF windows has to be closed which disrupting my work and not able to save.
PLEASE have the priority of this bug high!
THIS PROBLEM HAPPENS ALL THE TIME!!!
blocking2.0: - → ?
question: is this bug totally focused on the hang aspect of these dups?  If it doesn't attempt to address what is causing the unresponsive script pop up, then there's a big issue that isn't getting attention. Or has a core bug been identified that deals with that but isn't in this bug's dependencies?

Also, what is the earliest date of trunk build that shows this behavior?

Chronology of some reports:
bug 476541 - this bug - (20090202)
Bug 482811 - Unresponsive script timeout can cause hang if file dialog open (20090308)
Bug 451839 - Closing large html file that does DOM manipulation at startup is very slow - closing errors out with "unresponsive script (2008070206)
Blocks: 485398
Steven, shouldn't we widen this bug for all platforms? But I'm not sure because of your mentioned bug for OS X specifically.
note - I'm not suggesting this bug must change. it may be more appropriate or cleaner (I suspect) to 
a) keep the bugs separate by OS
b) find or create a core bug that best details with the script timeout part
(In reply to comment #61)

As far as I know this bug is specific to OS X.
potential dups for someone to act on:
Bug 542257
Bug 511570
Bug  543421
Bug 551473
Bug 566179
Bug 577932
Summary: Hang if page puts up an alert sheet while a modal dialog is open → Hang if page puts up an alert sheet while a modal dialog is open [Mac]
(In reply to comment #63)
> (In reply to comment #61)
> 
> As far as I know this bug is specific to OS X.

In this case the problem is with a user interface component specific to Mac OS X: the alert sheet, which pops up from just under the title bar of a window. The sheet itself is attached to a window, so it has no inherent controls of its own. I suppose a Motif XmDialog window could have similar behavior, though most window managers provide a Close operation even in a dialog's frame. Microsoft Windows is a whole different critter on its own.

While it may be possible to have something similar happen with other OS's, those other user interfaces could provide a means of escape that OS X doesn't. That makes it specifically nasty on that platform.
Minusing for blocking2.0, I'd still like to fix this but the blocking logic is no different now than for 1.9.1 or 1.9.2. We just haven't gotten to this yet unfortunately.
blocking2.0: ? → -
(In reply to comment #60)
> question: is this bug totally focused on the hang aspect of these dups?  If it
> doesn't attempt to address what is causing the unresponsive script pop up, then
> there's a big issue that isn't getting attention. Or has a core bug been
> identified that deals with that but isn't in this bug's dependencies?

IMO this bug *should* focus on the hang aspect of these bugs.  Yes, unresponsive scripts are an annoyance but in general they do not potentially cause a loss of data.  However, a deadlock between two modal UI elements, as demonstrated by this bug, does have the potential to lose data and cause a major inconvenience (i.e. lose the entire browsing session over multiple tabs and windows), rather than just a mild annoyance (fail to complete a single script in a single tab).

I understand the implied concern about fixing a symptom rather than an underlying problem, but in this case I think the hang problem is a genuine defect in its own right.  And my fear is that if attention is diverted away from the hang aspect, then there will always be more ways for scripts to become unresponsive and so the potential for this defect will always be there.
Another sample of Alert dialog which cause hanging FF:

"Alert : The document cannot change while printing or in print preview"

Again this happens on Mac OS 10,  
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11

and due to pdf printing!!
It has been so long since this bug is reported and apparently nothing is done!
(In reply to comment #67)
> I understand the implied concern about fixing a symptom rather than an
> underlying problem, but in this case I think the hang problem is a genuine
> defect in its own right.

Agreed. On an older, slower machine like mine (PowerMac G4 450 MHz ... cannot afford a new machine, sorry) script timeouts would be frequent if I didn't tweak the settings. The hang can occur anyhow.
I've just seen this on FF 3.6.12, 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12

There is probably a dupe at 595177
I got this bug using Thunderbird yesterday.

MacBook 2.4GHz Unibody 2008-11
Thunderbird 3.1.6.

“My patience is starting to be… empty”...
This is getting frusturating this isnt getting fixed :( 

Its an exploitable show stopper, and because it makes firefox unsuitable for office type work, it really needs to be a 'stop everything and fix this first' sort of thing.

I've had to resort to Chrome because i've lost too much work already :(
I ran into it in Thunderbird as well... Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
I got this yesterday in Minefield between a Master Password sheet and a filepicker, so it's really any sheet vs. any modal dialog from the look of it.

Is the logic for blocking documented somewhere? I don't understand the process that leads to something like this being minused for three branches in a row.
> Is the logic for blocking documented somewhere? I don't understand the process
> that leads to something like this being minused for three branches in a row.

CC'ing Brendan, who has mentioned some of the vagaries of alert() and blocking to me in the past.

Dave
funny you should mention Brendan. Is bug 618479 involved?  Firefox freezes on various terre-adelice.eu pages (unresponsive script)
(In reply to comment #81)

> CC'ing Brendan, who has mentioned some of the vagaries of alert() and blocking
> to me in the past.

Actually, I was referring to this:

(In reply to comment #66)
> Minusing for blocking2.0, I'd still like to fix this but the blocking logic is
> no different now than for 1.9.1 or 1.9.2. We just haven't gotten to this yet
> unfortunately.

This is the logic I'm trying to understand. This bug can cause data loss, is more than two years old, has 33 dupes here and another dozen or so on bug 482811, has been fixed once, and has been minused for three branches in a row.

The only logic I can find justified in this bug's history is that it would be better to fix it by rewriting gecko's window handling code. As I understand it, this was planned but not done for both 1.9.2 and 1.9.3/2.0.

There was a fix that we decided not to take in bug 468393, though I suspect there's been substantial bitrot since 1.9.1.

Can someone point me at something to read that would explain why this isn't blocking2.0, or what would have to change to make it so? I'm trying to learn here, not throwing stones.
I consider this a pretty serious issue too. It's enough to make me use Chrome as my main browser. Let's say you made changes to a page that was on your local machine and you go to save it. If any tab you have open becomes unresponsive while that save dialog is open, you're screwed. Also if you're trying to print something that only lets you view it once and something becomes unresponsive, same thing: you're screwed.
We don't need to block unrelated and unconnected pages' JS execution due to one of the pages flying an alert. We do need to block the parent window's JS execution, and any in connected windows/frames.

This bug should have been fixed a while ago. It's a stain on our escutcheon. At this point I can't see slipping Firefox 4 for it, but the tgood news is that we are going to a quarterly release schedule, so it should be fixed for Firefox 5. Josh?

/be
The impact is far worse than this is n mail where Bug #482811 depends on this, and mail gets lost frequently because this hasn't been fixed.
(In reply to comment #88)
> We don't need to block unrelated and unconnected pages' JS execution due to one
> of the pages flying an alert. We do need to block the parent window's JS
> execution, and any in connected windows/frames.
> 
> This bug should have been fixed a while ago. It's a stain on our escutcheon. At
> this point I can't see slipping Firefox 4 for it, but the tgood news is that we
> are going to a quarterly release schedule, so it should be fixed for Firefox 5.
> Josh?
> 
> /be

Watch whose escutcheons you stain, fella. :)

Seriously, though, allow me to vote '''against''' waiting until after Firefox 3, as one who is on an older PowerMac who has already been barred from the Intel-only Firefox 4 pre-releases. I realize it's probably severe enough to want to avoid regression back to OS X Tiger on a PowerMac, but it does strand those of us who just plain cannot afford new hardware right now.
I have had the same problem.  This is extremely annoying and I hope it will be fixed ASAP.  The error dialogs on Mac seem to be problematic in many ways.  This happens to me with Unresponsive Script errors and Connection Timeout errors.  I also get dozens of stacked errors sometimes.
I'm getting to the point that if someone doesn't actually pick this up, I'm going to release a working browser crash exploit to the press to force the issue. This is causing too many people to have to give up on firefox because currently its too dangerous to use firefox for mission critical work like intranets without potentially losing a lot of editing work.

Is there *ANY* way of getting this bug to the attention of developers, because its STILL not even got someone accepting the bug for work, after hundreds of complaints.

Can we at least set this as blocking? Its irresponsible for Mozilla to continue to ignore this bug.
Here here, its a repeatable, crashing, data-loss (especially in Thunderbird) bug that has been open for 2 years!
I believe Firefox 4 will at least mitigate this issue by not using the types of modal dialogs that sometimes lead to this hang. The alert dialogs are tab-modal.
Can that be backported to the 3.x line in the meantime?
I just installed FF4 and confirmed that this is still an issue. So there is nothing really to backport. Back to Chrome I guess.
I'm seeing the issue again with the "Save as" dialog. Using Firefox 4.0 and Firebug 1.7.0. Firefox hung in one of Firebug's scripts.

Note that I had not seen the issue for long, with Firefox 4 and Firebug betas.
Cross-posting this from bug 482811 while I'm posting to be added to CC list:

As a dirty hack, couldn't the file picker spawning code temporarily set dom.max_chrome_script_run_time to 0, then restore it once dismissed?  Yes, it's dirty, but if a proper fix requires "significant amounts of engineering effort" (#50) and people are losing data then perhaps it's justifiable.
I've seen this often too. Most recently an "unresponsive script" warning popped out in conjunction with an open file dialog. I had to force-quit Firefox and I'm not 100% sure if the version info is current because I also got the "you just upgraded" page (though that could be a relic of the failed session):

Firefox 3.6.17
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17
Whiteboard: [tb31wants] → [tbwants]
Blocks: 530608
Build ID: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0a1) Gecko/20110620 Firefox/7.0a1
I've recently got a Firefox freeze.

You have to have lock screen function activated:
1. have one tab open.
2. hit cmd+p, the print dialog appears. Leave it on the screen and don't touch the mouse until...
3. ... the mac locks the screen
4. unlock the screen 

Actual result: firefox frizzes
Expected results: firefox should not freeze
This issue is terrible! It affects me very often.

To reproduce:
- Save an attachment
- When the save dialog pops up, navigate away from TB
- Spend a few seconds away
- Come back

Expected: Save dialog still there and user able to interact with it normally

Actual:
- Find that the "Unresponsive Script" message is behind the Save dialog
- Cannot close Save Dialog
- Cannot close Unresponsive Script message
- Must force quit TB

My environment:
Mac Intel
Mac OS 10.6.7
TB 3.1.11
Since upgrading to Thunderbird 6.0, I am no longer able to reproduce this in Thunderbird on my Mac OX 10.6.8.

I hope the same is true for others.
(In reply to Rob from comment #115)
> Since upgrading to Thunderbird 6.0, I am no longer able to reproduce this in
> Thunderbird on my Mac OX 10.6.8.
> 
> I hope the same is true for others.

I was also unable to duplicate in Thunderbird 6.0 on OSX 10.6.8.
Reproduced in Thunderbird 6.0 on OS X 10.7.1:

1. Open an email with an attachment.
2. Right-click the attachment.
3. Choose Save as...
4. Alt-Tab to Firefox 6.0.
5. Interact with Firefox.
6. Alt-Tab back to Thunderbird.

Actual result: 
a. Clicking Cancel in the save dialog does nothing and sets the default back to Save.
b. Clicking Save allows you to do the save, but leaves the Save dialog open.
c. Moving the Save dialog reveals the Unresponsive script dialog, which cannot be interacted with.

So it looks like this bug, if fixed for OS X 10.6.8, has returned for 10.7.1.

*sigh*
My bad.  It doesn't complete the save.  I can create a new folder, or navigate between folders, but it doesn't save the file on clicking Save.
Depends on: 663275
Blocks: 566179
Still reproducible in Firefox 12.0a1 (2011-12-30) on OS X 10.6.8.
Blocks: 660460
So this bug has been reported almost 3 years ago, has been reported in many duplicate bug submissions, and it appears that no one has made any progress on it. When will it be assigned to someone to actually work on it and fix it?
Well I use Zimbra email now.  Bye Thunderbird as main email client.
Still reproducing. And, actually, crashing my Firefox almost daily, since I need to Save As... lots of files as pdf through the Print dialog, almost always immediately triggering this bug and requiring a force quit.
(In reply to Adam Leeds from comment #130)
> Still reproducing. And, actually, crashing my Firefox almost daily, since I
> need to Save As... lots of files as pdf through the Print dialog, almost
> always immediately triggering this bug and requiring a force quit.

Have you tried setting dom.max_chrome_script_run_time to 0?
I think I have experienced the same bug, when the "Unresponsive script" popup happens when I am in a "Save Page As" dialog, which is modal, so I cannot click on the "Unresponsive script" popup's buttons, but at the same time, clicking on the "Save Page As" buttons no longer do anything (i.e. I can't finish the Save Page As dialog). I have to kill the Firefox process to get round this problem.

I am using  Mac OS X 10.6.8, and I last noticed this problem about a month ago (with Firefox 9), but this may simply because the situation does not happen very often (the popup occurring during the "Save Page As" dialog). I also use Firefox on WIndows XP, and I have never seen this problem, but I have noticed a few times that I get a "unresponsive script" popup almost immediately after finishing the "Save Page As" dialog -- I don't know if this is a coincident, or if the popup was delayed until after the "Save Page As" dialog was finish (stopping such popups from occurring while you are in a modal dialog seems to be one way to solve this problem)
I've seen this bug happen several times recently in Firefox Aurora 12.0a2 on Mac OS 10.6.8.
I've got a patch and tryserver build at bug 729720 that may fix these hangs.  See bug 729720 comment #11.

Whoever can still reproduce this bug's hangs in current trunk nightlies, please try it out and let us know your results.
OS X 10.7.3/FF 11, reporting in. Fully reproducible.
Depends on: 729720
Build ID: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120502 Firefox/14.0a2

Ran into this with the Save Link As… app-modal window. Had that up, then the Master Password modal appeared while the Save window was still up. Couldn't Save or Cancel the Save window, and couldn't focus the Master Password dialog. Completely stuck.
This bug completely locks up the application, and in my case, "Force Quit" wasn't even an option.

Had to open a Terminal and use ps auxwww | grep Firefox to find the pid and kill -9 it.

I don't think many users will know how to do that...

At any rate, I hate to complain about free open source software, but there are a lot of votes for this.  Even more if you add up all the votes for the duplicates.

And it's been hanging around for over 2 years.

I'd take a shot at fixing it myself, but my C skills are so rusty that would be pointless.
To add a minor data point I am still seeing this issue with recent builds with the unresponsive script dialog. Neither it not the competing dialog accepts focus and force quit is the only escape.
STILL in FireFox 14.0.1

Getting really really really REALLY annoying.
Can't update flash, because during the "save file" dialog,
either (1) a cookie wants to get set, or (2) script is taking too long.
(In reply to Richard Lynch from comment #140)
> This bug completely locks up the application, and in my case, "Force Quit"
> wasn't even an option.
> 
> Had to open a Terminal and use ps auxwww | grep Firefox to find the pid and
> kill -9 it.
> 
> I don't think many users will know how to do that...
> 
> At any rate, I hate to complain about free open source software, but there
> are a lot of votes for this.  Even more if you add up all the votes for the
> duplicates.
> 
> And it's been hanging around for over 2 years.
> 
> I'd take a shot at fixing it myself, but my C skills are so rusty that would
> be pointless.

For what it's worth, you can make 'Force Quit' appear in a Dock right-click menu by halding down alt/option.
The bug is still present in Firefox 16.0.2. Pretty annoying, even though the automatic restore of tabs and windows mitigates the annoyance.
This is not just a rare minor annoyance for me...

I am very careful about cookies I allow, and have my preferences set that way.

I can't print nor save nor do much of anything without risk of the third-party cookies popping up a dialog at the most inconvenient time and locking up Firefox.

Advertisements that reload with changing/new cookies are particularly problematic.

Maybe I'm just the only user with these settings, or maybe I'm the only user to report them...
The filepicker now has an API to use async call. I think that should prevent this bug. What happens if you have an <input type='file'> and an alert? Does that break? If not, I think you should open a bug on Firefox to change their use of the file picker to use the async API. Feel free to CC me.
Regarding the print dialog, I don't think we have a fix yet. :(
Hi Mounir

Thank you for your message. Unfortunately, the deadlock occurs even with the filepicker. I have set up a simple test to trigger the bug.

Here is a direct link:
https://ocroquette.fr/firefox/

Here is the HTML code:
<!DOCTYPE html>
<html>
<body>
<script>
window.setTimeout("while(1) { }",5000);
</script>
<ul>
<li>Click on "Browse" within 5s
<li>The modal file dialog opens
<li>Wait
<li>The endless Javascript loop starts
<li>The "unresponsive script" modal dialog appears
<li>GUI DEADLOCK (on MacOS X at least)
<ul>
<input type="file">
</body>
</html>
I'm afraid I can't help much then. I do not know much about our MacOS X code and I do not use MacOS.
Bug 731307 added support for an asynchronous nsIFilePicker.  And in principal it includes changes that'd make the code from comment #149 spawn an asynchronous filepicker.  But, because of the way modal dialogs work on OS X, an asynchronous file picker *must* be either a sheet (if it's a native object) or a tab-modal "html window".  (See bug 478073.)

What kind of filepicker do you get running the code from comment #149?  If it's a native window, it won't work properly.

I still intend to keep working on the Mac-specific side of this problem at bug 729720.  But lately I haven't had much time to devote to it.
Note that the patches for bug 731307 haven't yet gotten into a release.  But they *are* in the Firefox 17 betas.
Firefox 17 is now released, as of a few hours ago :)
In case anyone is wondering, the problem is still present in Firefox 17.

PS: I didn't realize the initial bug report already contained an example to trigger it, sorry. Now we have 2 :)
Still an issue in FF 19
Still present in FF 20.0
Flags: wanted1.9.2?
Still present in FF 25.0.x (and Nightly 28)
The problem is also triggered if you leave the save dialog open too long when saving pages/screenshots with "Pearl Crescent Page Saver Basic" (http://pearlcrescent.com/products/pagesaver/).
Still present in Nightly 31.
Flags: firefox-backlog?
Flags: firefox-backlog? → firefox-backlog+
Flags: firefox-backlog+ → firefox-backlog-
I actually think it was a mistake to merge the unresponsive script dialog bugs with this one. The two issues should be un-unified, if that’s even possible. The two are separate but related issues.

The thing with the unresponsive script dialogs is that when a modal dialog is open, Firefox should not even be monitoring for unresponsive scripts because the modal dialog will block the execution of scripts, so scripts will always be wrongly detected as unresponsive.
> The thing with the unresponsive script dialogs is that when a modal
> dialog is open, Firefox should not even be monitoring for
> unresponsive scripts because the modal dialog will block the
> execution of scripts, so scripts will always be wrongly detected as
> unresponsive.

Interesting idea ... though I'm not sure it's true that a modal dialog
always blocks the execution of scripts.

Please open a new bug on this, so we can pursue the discussion
elsewhere.

Give it a subject something like "Unresponsive script dialogs
shouldn't appear when a modal dialog is displayed".  Categorize it as
"Core : XPConnect".  When you're done post the bug number here.
Blocks: 705568
See also Bug 1224790 comment 18 for an analysis; that bug fixes some but not all modal issues noted here.
Following the STR's in comment #0, this is WFM on latest Nightly 49.0a1, 20160531030258
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Depends on: e10s
No, this is not fixed.
still reproducible on Nightly 52.0a1 (2016-10-06) (64-bit), non-e10s, on OSX.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: Hang if page puts up an alert sheet while a modal dialog is open [Mac] → [non-e10s] Hang if page puts up an alert sheet while a modal dialog is open [Mac]
:arai, can you provide more details about what OS you're using, how to reproduce, and exactly what you're seeing? I was under the impression this should have gotten better as a result of bug 1260850 for the OS X issue originally reported here.
Flags: needinfo?(arai.unmht)
(In reply to :Gijs Kruitbosch from comment #186)
> :arai, can you provide more details about what OS you're using, how to
> reproduce, and exactly what you're seeing? I was under the impression this
> should have gotten better as a result of bug 1260850 for the OS X issue
> originally reported here.

I'm on OSX 10.11.6.

Steps To Reproduce:
  1. Run Nightly
  2. Open about:preferences
  3. Uncheck "Enable multi-process Nightly"
  4. Restart Nightly
  5. Load https://bugzilla.mozilla.org/attachment.cgi?id=351645
  6. Hit Cmd+S to open the Save As before the alert comes up
  7. Wait for 5 seconds to the alert comes up

step 3 is important here, because the issue is not reproducible on e10s, and now e10s is enabled by default on Nightly,
so just following the steps in comment #0 executes different code path.


Actual result:
  * "Cancel" button in the Save As dialog does nothing
  * "Save" button in the Save As dialog does almost nothing
    If there's the same filename, it opens another modal dialog about replace
    ("test.html" already exists. Do you want to replace it?)
    but clicking "Cancel" or "Replace" just closes the modal dialog, doesn't close the Save As dialog
but
  * Browser window keeps responsive
    I can switch between tabs, open tabs, load pages
  * The alert and the Save As dialog can be closed by the following steps:
      1. click "OK" in the alert
      2. click "Cancel" in the Save As dialog
    this is not intuitive, as the Save As dialog is shown a top of the alert


Expected result:
  * "Cancel" button and "Save" button should work as usual
Flags: needinfo?(arai.unmht)
Whiteboard: [tbwants] → [tbwants[tpi:+]
Whiteboard: [tbwants[tpi:+] → [tbwants][tpi:+][tpi-help-requested]
Adjusting priority since e10s is now turned on by default and this bug only occurs in non-e10s (see comment 187).
Severity: critical → normal
Priority: P2 → P3
Blocks: 1609234
Blocks: 1652455
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 74 duplicates, 52 votes and 144 CCs.
:spohl, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(spohl.mozilla.bugs)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(spohl.mozilla.bugs)

Non-e10s is no longer supported so I think this can be closed as WFM.

Status: REOPENED → RESOLVED
Closed: 8 years ago → 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: