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

REOPENED
Unassigned

Status

()

Core
Widget: Cocoa
P2
critical
REOPENED
8 years ago
4 months ago

People

(Reporter: whimboo, Unassigned)

Tracking

(Depends on: 2 bugs, Blocks: 2 bugs, {hang, testcase})

Trunk
x86
Mac OS X
hang, testcase
Points:
---

Firefox Tracking Flags

(blocking2.0 -)

Details

(Whiteboard: [tbwants][tpi:+][tpi-help-requested], URL)

Attachments

(6 attachments)

(Reporter)

Description

8 years ago
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?
There is a patch for this at bug 468393 (attachment 356977 [details] [diff] [review]).
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.

Comment 3

8 years ago
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-
Duplicate of this bug: 478456
Duplicate of this bug: 488902

Updated

8 years ago
Assignee: joshmoz → nobody
Blocks: 482811

Comment 6

8 years ago
Created attachment 394986 [details]
image of two blocked dialog boxes

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
(Reporter)

Updated

8 years ago
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
(Reporter)

Updated

8 years ago
Duplicate of this bug: 509709
(Reporter)

Updated

8 years ago
Duplicate of this bug: 488079
(Reporter)

Updated

8 years ago
Duplicate of this bug: 500412
Duplicate of this bug: 519757
Duplicate of this bug: 522092

Comment 12

8 years ago
Perhaps Bug 479749 is a duplicate as well?

Comment 13

8 years ago
(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]
(Reporter)

Comment 15

8 years ago
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: --- → ?

Comment 16

8 years ago
I can also reproduce this with this url:

data:text/html,<iframe src="javascript:print()"></iframe><iframe src="javascript:alert(0)"></iframe>
Duplicate of this bug: 541257

Updated

7 years ago
Duplicate of this bug: 542556
(Reporter)

Comment 19

7 years ago
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.
Duplicate of this bug: 555232
Josh, would you make a blocking call on this?
How far did we get with the 1.9.2 work described in comment 3?

Comment 23

7 years ago
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: ? → -
Duplicate of this bug: 558797

Comment 25

7 years ago
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.
Duplicate of this bug: 456993
Duplicate of this bug: 559244
Duplicate of this bug: 561193
Duplicate of this bug: 561983
Duplicate of this bug: 561865

Comment 31

7 years ago
Created attachment 442019 [details]
The "Save As" dialogue is interrupted by a Gmail calendar reminder.

Comment 32

7 years ago
Created attachment 442187 [details]
The same problem occurs in Thunderbird, if this alert (GnuPG not found, see image) pops up while in a "save as..." dialog.

This problem occurs in both, Firefox and Thunderbird.
Duplicate of this bug: 562869

Comment 34

7 years ago
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.

Comment 35

7 years ago
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.

Comment 36

7 years ago
What I can guess is that there are scripts in other places too, non only in shown pages (eg.: the Stylish plug-in).

Comment 37

7 years ago
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.

Comment 38

7 years ago
Created attachment 449180 [details]
Unresponsive Script Dialog Box

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.
Duplicate of this bug: 577244

Updated

7 years ago
Duplicate of this bug: 482811

Updated

7 years ago
Duplicate of this bug: 485398
Duplicate of this bug: 528149
Duplicate of this bug: 583512

Comment 44

7 years ago
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.

Updated

7 years ago
Duplicate of this bug: 585549

Comment 46

7 years ago
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.
Duplicate of this bug: 586326

Comment 48

7 years ago
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.
Duplicate of this bug: 591675

Comment 50

7 years ago
No one assigned to fix this?  How can that be induced?

Comment 51

7 years ago
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.

Comment 52

7 years ago
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.

Comment 53

7 years ago
that's offtopic. try google? http://forums.mozillazine.org/viewtopic.php?t=100594

Comment 54

7 years ago
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

Updated

7 years ago
OS: Mac OS X → Windows XP

Comment 55

7 years ago
I assume that change to Windows XP wasn't intentional, since Windows doesn't have Widget:Cocoa...
OS: Windows XP → Mac OS X

Comment 56

7 years ago
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?

Comment 57

7 years ago
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
Duplicate of this bug: 605842

Comment 59

7 years ago
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!!!

Updated

7 years ago
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
(Reporter)

Comment 61

7 years ago
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]

Comment 65

7 years ago
(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.

Comment 66

7 years ago
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: ? → -

Comment 67

7 years ago
(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.
Duplicate of this bug: 577932
Duplicate of this bug: 590914
Duplicate of this bug: 606887

Comment 71

7 years ago
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!

Comment 72

7 years ago
(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.

Comment 73

7 years ago
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
Duplicate of this bug: 613144
Duplicate of this bug: 613303

Comment 76

7 years ago
I got this bug using Thunderbird yesterday.

MacBook 2.4GHz Unibody 2008-11
Thunderbird 3.1.6.

“My patience is starting to be… empty”...
Duplicate of this bug: 618873

Comment 78

7 years ago
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 :(

Comment 79

7 years ago
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
Duplicate of this bug: 507332
Duplicate of this bug: 595177
Duplicate of this bug: 577787
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.

Comment 87

7 years ago
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

Comment 89

7 years ago
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.

Comment 90

7 years ago
(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.
Duplicate of this bug: 615931

Updated

7 years ago
Duplicate of this bug: 551473
Duplicate of this bug: 627733
Duplicate of this bug: 499562
Duplicate of this bug: 591842

Comment 96

6 years ago
Created attachment 514743 [details]
"Unresponsive Script" dialog can't be dismissed and Open File can't Cancel or Save

Comment 97

6 years ago
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.

Comment 98

6 years ago
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.

Comment 99

6 years ago
Here here, its a repeatable, crashing, data-loss (especially in Thunderbird) bug that has been open for 2 years!

Comment 100

6 years ago
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.

Comment 101

6 years ago
Can that be backported to the 3.x line in the meantime?

Comment 102

6 years ago
I just installed FF4 and confirmed that this is still an issue. So there is nothing really to backport. Back to Chrome I guess.

Comment 103

6 years ago
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.
Duplicate of this bug: 647721
Duplicate of this bug: 655502
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.

Comment 107

6 years ago
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

Comment 108

6 years ago
Created attachment 532768 [details]
With an unresponsive script dialog active, neither that dialog nor Open File can be dismissed

Just another annoying example.
Duplicate of this bug: 652898
Whiteboard: [tb31wants] → [tbwants]
Duplicate of this bug: 511570
Blocks: 530608

Comment 111

6 years ago
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

Updated

6 years ago
Duplicate of this bug: 663275

Comment 113

6 years ago
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
Duplicate of this bug: 682605

Comment 115

6 years ago
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.

Comment 116

6 years ago
(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.

Comment 117

6 years ago
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*

Comment 118

6 years ago
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.
Duplicate of this bug: 586896
Depends on: 663275
Duplicate of this bug: 555385
Blocks: 566179
Duplicate of this bug: 711783
Still reproducible in Firefox 12.0a1 (2011-12-30) on OS X 10.6.8.
Blocks: 660460
Duplicate of this bug: 660460

Comment 124

6 years ago
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?
Duplicate of this bug: 718542
Duplicate of this bug: 703022
Duplicate of this bug: 721889

Comment 128

5 years ago
Well I use Zimbra email now.  Bye Thunderbird as main email client.
Duplicate of this bug: 725034

Comment 130

5 years ago
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.

Comment 131

5 years ago
(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?

Comment 132

5 years ago
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)

Comment 133

5 years ago
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.

Updated

5 years ago
Duplicate of this bug: 735992

Comment 136

5 years ago
OS X 10.7.3/FF 11, reporting in. Fully reproducible.
Depends on: 729720

Comment 137

5 years ago
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.
Duplicate of this bug: 766212
Duplicate of this bug: 779023

Comment 140

5 years ago
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.

Comment 141

5 years ago
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.

Comment 142

5 years ago
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.

Comment 143

5 years ago
(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.
Duplicate of this bug: 793402
Duplicate of this bug: 807558

Comment 146

5 years ago
The bug is still present in Firefox 16.0.2. Pretty annoying, even though the automatic restore of tabs and windows mitigates the annoyance.

Comment 147

5 years ago
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. :(

Comment 149

5 years ago
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 :)

Comment 154

5 years 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 :)

Comment 155

4 years ago
Still an issue in FF 19
Comment hidden (advocacy)
Duplicate of this bug: 854216

Comment 158

4 years ago
Still present in FF 20.0
(Reporter)

Updated

4 years ago
Flags: wanted1.9.2?
Duplicate of this bug: 796986

Updated

4 years ago
Duplicate of this bug: 867806

Updated

4 years ago
Duplicate of this bug: 448452

Updated

4 years ago
Duplicate of this bug: 640973

Comment 163

4 years ago
Still present in FF 25.0.x (and Nightly 28)

Comment 164

4 years ago
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/).
Duplicate of this bug: 992490

Comment 166

3 years ago
Still present in Nightly 31.
Duplicate of this bug: 1000235

Updated

3 years ago
Flags: firefox-backlog?

Updated

3 years ago
Flags: firefox-backlog? → firefox-backlog+
Flags: firefox-backlog+ → firefox-backlog-

Comment 168

3 years ago
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.

Updated

3 years ago
Duplicate of this bug: 1028864
Duplicate of this bug: 945388
Duplicate of this bug: 1081718
Duplicate of this bug: 1094831
Duplicate of this bug: 714212

Updated

2 years ago
Duplicate of this bug: 1164411

Updated

2 years ago
Duplicate of this bug: 956618
Duplicate of this bug: 1173741

Updated

2 years ago
Duplicate of this bug: 1172962
Blocks: 705568

Updated

2 years ago
Blocks: 711808
Duplicate of this bug: 712633

Comment 180

2 years ago
See also Bug 1224790 comment 18 for an analysis; that bug fixes some but not all modal issues noted here.
Duplicate of this bug: 982762

Updated

a year ago
Duplicate of this bug: 1172236
Duplicate of this bug: 1238787
See Also: → bug 1224790
Following the STR's in comment #0, this is WFM on latest Nightly 49.0a1, 20160531030258
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WORKSFORME
Depends on: 516752
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]

Comment 186

8 months ago
: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)

Updated

7 months ago
Whiteboard: [tbwants] → [tbwants[tpi:+]

Updated

4 months ago
Whiteboard: [tbwants[tpi:+] → [tbwants][tpi:+][tpi-help-requested]
You need to log in before you can comment on or make changes to this bug.