Last Comment Bug 482811 - Unresponsive script timeout can cause hang if file dialog open (attachment, save file etc) [Mac]
: Unresponsive script timeout can cause hang if file dialog open (attachment, s...
Status: RESOLVED FIXED
[duptome][ref: comment 18][keep in Th...
: hang, regression
Product: Thunderbird
Classification: Client Software
Component: General (show other bugs)
: unspecified
: x86 Mac OS X
: -- critical with 19 votes (vote)
: Thunderbird 17.0
Assigned To: :Irving Reid (No longer working on Firefox)
:
:
Mentors:
https://getsatisfaction.com/mozilla_m...
: 564416 570300 576162 577502 578046 587692 587706 594805 598253 598260 602462 603645 621035 625225 635565 638510 658895 668481 681453 721716 737096 747769 (view as bug list)
Depends on: 478073 783344 476541
Blocks: 570300 575359 593847
  Show dependency treegraph
 
Reported: 2009-03-11 14:48 PDT by Mitra Ardron
Modified: 2013-05-02 03:45 PDT (History)
54 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
-
fixed
fixed


Attachments
Screenshot of unresponsive script hang #1 (140.54 KB, image/png)
2010-02-10 18:09 PST, WD
no flags Details
Screenshot of unresponsive script hang #2 (105.14 KB, image/png)
2010-02-10 18:10 PST, WD
no flags Details
Screenshot of T'bird script hang with open file dialog (48.19 KB, image/tiff)
2010-11-19 11:49 PST, Tom Phinney
no flags Details
Screenshot of T'bird canceling shutdown after script hang with open file dialog (26.11 KB, image/tiff)
2010-11-19 11:50 PST, Tom Phinney
no flags Details
"Warning: Unresponsive Script" dialog and File browser, 4 buttons, none work (74.82 KB, image/png)
2011-09-04 08:36 PDT, Derek Williams
no flags Details
"Server not found" when image access attempted (194.37 KB, image/png)
2011-09-04 08:41 PDT, Derek Williams
no flags Details
THIS IS NOT FIXED! (95.94 KB, image/png)
2012-04-11 15:30 PDT, Derek Williams
no flags Details
Is hanging a feature or a bug of Thunderbird? (203.04 KB, image/png)
2012-07-28 06:58 PDT, Derek Williams
no flags Details
Disable slow chrome script warning on Mac OS (1.10 KB, patch)
2012-08-16 12:26 PDT, :Irving Reid (No longer working on Firefox)
standard8: review+
standard8: approval‑comm‑aurora+
standard8: approval‑comm‑beta+
Details | Diff | Splinter Review

Description Mitra Ardron 2009-03-11 14:48:08 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090308 Shredder/3.0b3pre

The Dialogue about unresponsive scripts can itself latch TB up if there is another dialogue (e.g. a file chooser window) open at the same time.

Reproducible: Always

Steps to Reproduce:
1. Open a message with an attachement
2. ctrl-click detach-all 
3. Wait till the File system dialog opens
4. Go elsewhere, ignore TB for a while - I hit this because I saw the file was going to overwrite something and needed to do something with that file first.
5. Eventually a dialogue appears saying that a script has timed out and giving the option of continue or cancel
6. Neither this dialogue, nor the file chooser work at this point, 
7. Force-Quit seems the only way out.
Comment 1 Mark Banner (:standard8) 2009-05-04 05:08:06 PDT
I see this as well on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090503 Lightning/1.0pre Shredder/3.0b3pre.

Looks like bug 476541 would fix this, however confirming so that we have a known TB tracker version.
Comment 2 Wayne Mery (:wsmwk, NI for questions) 2010-01-01 10:43:50 PST
bug 485398 a dup?
Comment 3 Mitra Ardron 2010-01-01 13:54:11 PST
Could be - though its Mac v. Unix and in bug 49538 comment 3 it suggests they are handled differently.
Comment 4 WD 2010-02-10 18:09:04 PST
This happened to me twice today with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6

While a file save dialog was open, an unresponsive script dialog came up.  At this point, the save file dialog cannot be dismissed, nor can the unresponsive script dialog be interacted with.   It required a "Force Quit" of the Firefox process.
Comment 5 WD 2010-02-10 18:09:54 PST
Created attachment 426405 [details]
Screenshot of unresponsive script hang #1
Comment 6 WD 2010-02-10 18:10:41 PST
Created attachment 426406 [details]
Screenshot of unresponsive script hang #2
Comment 7 jeffrey.glickman 2010-05-23 22:51:17 PDT
I just had this problem occur while trying to print a confirmation page to PDF.

The print dialog was open, the unresponsive script dialog opened below it. Impossible to close the Print dialog, but also unable to continue unresponsive script.

Very, very annoying that I lost a rather important page that cannot be regenerated thanks to this bug.
Comment 8 Jonathan Protzenko [:protz] 2010-06-28 12:02:26 PDT
Confirmed on Linux as well, this time with the "save all attachments" dialog.
Comment 9 [:Aureliano Buendía] 2010-06-29 02:30:00 PDT
(In reply to comment #2)
> bug 485398 a dup?

@Wayne:

Surely, this issue is a dupe of bug #485398 (the underlying problem and behavior is the same).

But after reading with attention, for me, basically this issue and bug #485398 are both dupes of bug #476541.

For me we can close as dupes.
Comment 10 Mitra Ardron 2010-06-30 21:33:56 PDT
Since this crashing bug has been marked as Critical now for a bit over a year and a half, I guess we can assume its not going to get fixed! 

I'd like to suggest a quick hack to REMOVE the unresponsive script check. I've never ever seen it occur due to a real script timeout, only from failing to respond to a dialog (e.g. most commonly a file attach when you realise you need to do something to the file first). 

So we have something in the code that is supposed to rescue problems, but causes more problems itself - can it just be removed until someone wants to fix the unresponsive script check? 

- Mitra
*Groutchy cos I just lost an email I'd spent an hour typing*
Comment 11 [:Aureliano Buendía] 2010-07-09 00:11:06 PDT
*** Bug 577502 has been marked as a duplicate of this bug. ***
Comment 12 Wayne Mery (:wsmwk, NI for questions) 2010-07-09 08:19:19 PDT
(In reply to comment #10)
> Since this crashing bug has been marked as Critical now for a bit over a year
> and a half, I guess we can assume its not going to get fixed! 

no doubt we are waiting on some core issue being fixed, so I think your assumption is incorrect. I'm not convinced in your case it is bug 476541, but I'm not a Mac user, so I'm not in a great position to offer good insight, etc.  Have you reviewed 476541 and similar bugs?  Also, how is it that you lost an email? Did you also lose a saved draft in the process? (or do you not save drafts?)

Aureliano may be on to something -  but I've been in un-bugzilla mode for the last couple weeks so unfortunately I haven't had time to research.
Comment 13 Joe Sewell 2010-07-09 14:46:11 PDT
(In reply to comment #10)
> I'd like to suggest a quick hack to REMOVE the unresponsive script check. I've
> never ever seen it occur due to a real script timeout, only from failing to
> respond to a dialog (e.g. most commonly a file attach when you realise you need
> to do something to the file first). 

I've had some situations where this is not the case, so I'm hesitant to suggest removing the check outright.

On the other hand, there *are* ways to deactivate the script check now. AFAIK it applies to the entire Mozilla suite. (Verified Camino, Seamonkey, TB, FF.) Set dom.max_script_run_time to 0 to disable the check on most scripts. Set dom.max_chrome_script_run_time to 0 to disable the check on built-in or add-on scripts.
Comment 14 Mitra Ardron 2010-07-10 04:00:35 PDT
Wayne - If there is some other issue driving this bug, then it would be good to flag it here, otherwise we'll just think bug reports get ignored! 

Sure - if I'd hit Save it would have been a bit less of a loss, that doesn't make it reasonable for TB to crash and lose data as several people have reported here and on the duplicate bugs. 

This bug is really really easy to repeat - I'd have thought someone could figure out how to fix it by now?

If you don't want to disable script checking then maybe just make sure that the TB dialog boxes (like Attach File) aren't treated as a running script. 

I'll stop complaining now as I've just followed Joe's suggestion and disabled script checking, but there's probably a lot more people losing data over this who aren't reporting bugs.
Comment 15 timeless 2010-07-10 15:00:21 PDT

*** This bug has been marked as a duplicate of bug 476541 ***
Comment 16 Wayne Mery (:wsmwk, NI for questions) 2010-07-13 03:53:21 PDT
unduping. Mark had left this open to keep a visible bug in thunderbird component. In addition, this is a two headed monster 
- aspect one is, what is causing the timeout - something which is yet to be determined
- aspect two is the hang.  
  or crash - as I am able to reproduce on windows bp-562b4e8f-5dfb-4c30-a701-62baa2100711

more bug consolidation later. Or someone can do more research with https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=anywordssubstr&short_desc=unresponsive%20script&field0-0-0=short_desc&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=enhancement&resolution=---&resolution=INVALID&resolution=DUPLICATE&resolution=WORKSFORME&classification=Client%20Software&classification=Components&query_format=advanced&longdesc=extension%20add-on&short_desc_type=substring&type0-0-0=nowords&value0-0-0=count%20counts&field1-0-0=short_desc&longdesc_type=anywordssubstr
Comment 17 Wayne Mery (:wsmwk, NI for questions) 2010-07-13 04:14:15 PDT
to amplify on aspect 1, the number of reports of this issue seems to have increased with version 3.1

Mitra, I was not suggesting this was good behavior
Comment 18 timeless 2010-07-13 04:51:53 PDT
so, err.

js calls a filepicker.

the file picker calls w32 which opens a window (the dialog) and pushes an event loop.

timers fire looking for unresponsive scripts, they find one.

there shouldn't be any rocket science here.
Comment 19 Wayne Mery (:wsmwk, NI for questions) 2010-07-15 05:41:52 PDT
(In reply to comment #18)
> timers fire looking for unresponsive scripts, they find one.
> 
> there shouldn't be any rocket science here.

indeed. but how to avoid these unresponsive script failures *in Thunderbird*? And is there a bug open for it?
Comment 20 Wayne Mery (:wsmwk, NI for questions) 2010-07-15 05:42:14 PDT
*** Bug 570300 has been marked as a duplicate of this bug. ***
Comment 21 Wayne Mery (:wsmwk, NI for questions) 2010-07-15 05:42:56 PDT
*** Bug 578046 has been marked as a duplicate of this bug. ***
Comment 22 Joe Sewell 2010-07-15 16:09:02 PDT
(In reply to comment #18)
> so, err.
> 
> js calls a filepicker.
> 
> the file picker calls w32 which opens a window (the dialog) and pushes an event
> loop.
> 
> timers fire looking for unresponsive scripts, they find one.
> 
> there shouldn't be any rocket science here.

Disagree. IF this is the same thing I've seen in Firefox, there was no separate dialog involved. Assuming this is an issue in the lower widget layer, the dialog simply helps reproduce the case more consistently than what I've seen.

Wayne: I also disagree with changing it from a widget-layer bug to a Thunderbird bug. Unless you have some additional information leading you to believe this, I suggest keeping it at the lower level for now.
Comment 23 dave white 2010-08-03 17:19:22 PDT
Am able to duplicate this in Mac 3.1.1 also.  Has happened twice during normal usage in the last week while multitasking away from mail when I have an attachment dialog up.
Comment 24 Mark Banner (:standard8) 2010-08-16 11:10:27 PDT
*** Bug 587692 has been marked as a duplicate of this bug. ***
Comment 25 Mark Banner (:standard8) 2010-08-16 11:10:36 PDT
*** Bug 587706 has been marked as a duplicate of this bug. ***
Comment 27 Robert Goldman 2010-08-18 20:41:17 PDT
Just locked up for me on TBird v. 3.1.2 on Mac OSX.  Quite annoying because it is a work-losing bug.  Happened to me on a very long email I was writing, all of which I will now have to retype :-(
Comment 28 Wayne Mery (:wsmwk, NI for questions) 2010-09-28 07:44:25 PDT
*** Bug 598253 has been marked as a duplicate of this bug. ***
Comment 29 Dmitry Panov 2010-10-01 11:01:54 PDT
I have been able to reproduce the bug in TB 3.1.4/mac several times. 
It's very easy to reproduce, just leave the "Add Attachment" dialog window alone for a while. Really annoying one, please fix.
Comment 30 Wayne Mery (:wsmwk, NI for questions) 2010-10-21 05:44:39 PDT
*** Bug 594805 has been marked as a duplicate of this bug. ***
Comment 31 Michael 2010-10-21 10:07:31 PDT
I'm not sure what the progress on resolving this issue is, but I'll add my vote: this is incredibly annoying because there is no graceful way to quit. Dmitry's Comment 29 illustrates exactly how easy it is to reproduce. I assume at that point one could attach a debugger and see just what threads are sitting around and what conditionals they are testing.

After peering through this conversation, I now know the (obscure) name of a config parameter that I can alter, but that doesn't help people when they first get bitten.

There actually seem to be two issues here: (1) the too-short timeout triggering the "unresponsive script" dialog and (2) the inability of that dialog to be dismissed.

The first issue doesn't seem to be an error in _code_; rather it appears to be an error in the assumed defaults for distinguishing between a human who is off taking a long time to generate the attachment to be added and a "genuine" unresponsive filepicker dialog box. In both cases, the filepicker is sitting around doing nothing.

The second issue does seem like buggy code; whatever check is controlling the "unresponsive script" dialog box seems to remain true even after the user attempts to dismiss it. I'll note that in my case, I can dismiss neither the "unresponsive script" box nor the "add attachement" filepicker. Perhaps part of the condition controlling the "unresponsive script" box is testing for whether the filepicker has gone away...since it hasn't, the unresponsive script still believes it has to appear. I don't know enough about TB internals to know whether this should solely be classified as TB layer or widget layer as someone suggested above; it seems to me that this is a cross-layer problem: you have a component of TB (the unresponsive script box) potentially relying on the state of a widget (the filepicker) --- but this is pure speculation, someone more familiar may be able to figure this out.

As a way of avoiding triggering this problem, perhaps it would be useful to somehow distinguish between the small set of standard scripts that TB knows a user will be interacting with (such as "add attachement") and other third-party scripts, and then either set a really long timeout value as a default or disable the "hang" detector entirely for that small set.

Thunderbird 3.1.5, Mac OS X 10.5.8
Comment 32 Wayne Mery (:wsmwk, NI for questions) 2010-10-21 13:31:39 PDT
*** Bug 576162 has been marked as a duplicate of this bug. ***
Comment 33 Wayne Mery (:wsmwk, NI for questions) 2010-10-21 13:48:10 PDT
*** Bug 602462 has been marked as a duplicate of this bug. ***
Comment 34 Yansky 2010-11-07 01:07:25 PDT
I've also encountered this but with a slightly different setup. I clicked on the install link on the addons page to install an addon, I switched tabs then right-clicked on a download link and the save dialogue box popped up. Before I could click on the save button, the install box popped under and made it impossible to save or cancel the download. I had to force-quit firefox.

I'm running Firefox 3.6.12 on OSX 10.6.

Here is a screenshot of what it looked like: http://img214.imageshack.us/img214/4958/screenshot20101107at7.png
Comment 35 Joe Sewell 2010-11-07 13:22:21 PST
(In reply to comment #34)
> I've also encountered this but with a slightly different setup. I clicked on
> the install link on the addons page to install an addon, I switched tabs then
> right-clicked on a download link and the save dialogue box popped up. Before I
> could click on the save button, the install box popped under and made it
> impossible to save or cancel the download. I had to force-quit firefox.
> 
> I'm running Firefox 3.6.12 on OSX 10.6.
> 
> Here is a screenshot of what it looked like:
> http://img214.imageshack.us/img214/4958/screenshot20101107at7.png

I assume you couldn't cancel the install, either?

If that's the case, then we're looking more at a deadlock situation rather than a UI issue.
Comment 36 Yansky 2010-11-07 14:15:53 PST
(In reply to comment #35)
> (In reply to comment #34)
> > I've also encountered this but with a slightly different setup. I clicked on
> > the install link on the addons page to install an addon, I switched tabs then
> > right-clicked on a download link and the save dialogue box popped up. Before I
> > could click on the save button, the install box popped under and made it
> > impossible to save or cancel the download. I had to force-quit firefox.
> > 
> > I'm running Firefox 3.6.12 on OSX 10.6.
> > 
> > Here is a screenshot of what it looked like:
> > http://img214.imageshack.us/img214/4958/screenshot20101107at7.png
> 
> I assume you couldn't cancel the install, either?
> 
> If that's the case, then we're looking more at a deadlock situation rather than
> a UI issue.

Yep, I couldn't cancel either.

Should I open a new bug if it's a different issue?
Comment 37 Joe Sewell 2010-11-08 17:22:46 PST
No, it could very well be the same bug, just a different view of it.
Comment 38 Tom Phinney 2010-11-19 11:49:23 PST
Created attachment 491905 [details]
Screenshot of T'bird script hang with open file dialog
Comment 39 Tom Phinney 2010-11-19 11:50:05 PST
Created attachment 491906 [details]
Screenshot of T'bird canceling shutdown after script hang with open file dialog
Comment 40 Tom Phinney 2010-11-19 11:58:16 PST
Comment on attachment 491905 [details]
Screenshot of T'bird script hang with open file dialog

I have had this problem in recent current versions of both T'bird and Firefox. It happens any time I change focus while a file attach, open or save dialog is open. I am running Mac OS X 10.5, T'bird 3.1.5, and Firefox 3.6.11 with NoScript and other goodies. For me this problem is fatal, since T'bird and Firefox ignore commands to quit and also cancel any ordered OS shutdowns (see second attached image).  The only solution for me is to close all other programs and eject all extra storage volumes, then hold the power button down for 4 s, forcing a hard shutdown. Then to be safe I have to boot to an alternate boot HDD and verify/repair the primary HDD volume on which I just forced the shutdown, in case that caused any file structure damage.  This is a big PITA, that costs at least 20 minutes until I'm back in operation.  Please, please fix the code base for both these products so that this damn unresponsive script warning is not allowed to activate when an OS file dialog is open.
Comment 41 Chris Pepper 2010-11-19 15:18:57 PST
Tom,

FWIW, I'm pretty sure I have never had to reboot Thunderbird for this bug. You should be able to Force Quit -- either by hitting Command-Option-Esc and picking the bad actor from the list that pops up; or by Control-clicking it in the Dock to pop up a menu, holding Command-Option, and clicking the Force Quit option that shows up.
Comment 42 [:Aureliano Buendía] 2010-12-27 05:25:04 PST
*** Bug 621035 has been marked as a duplicate of this bug. ***
Comment 43 Ludovic Hirlimann [:Usul] 2010-12-30 02:23:14 PST
11 dups and counting -> Requesting blocking for 3.3

Wayne waht was your though when you added the qawanted keyword ?
Comment 44 Wayne Mery (:wsmwk, NI for questions) 2010-12-30 06:58:58 PST
ludo,

"unresponsive script" is widely reported in newsgroups, gfsn and on mozillazine.

re: qawanted here, this bug a great starting point because we have a clearly defined, reproducible case of "unresponsive script". I've already done a lot of legwork in organizing the problem, so it should be easy for for someone with a little time to pony up to do one or both of the following
1. easy - determine the regression range - which may be as simple as confirming the regression range I posted in 493578 comment 7 (and 
2. debug instrument or trace the code to understand why unresponsive script is being triggered

Note: 
a) this is NOT just a Mac issue - although on Mac the situation often leads to hangs (bug 476541 - which surprisingly is going nowhere)
b) on windows I suspect some people see crashes - based on crash comments

related/dupe bugs:
Bug 575359 - Save all attachments dialog doesn't work (Unresponsive script) + weird behavior
Bug 577524 - Unresponsive script warning when saving multiple attachments


More generally - my hope is if we find the regression checkin that affects attachments, that it will lead to solutions for the other reports of "unresponsive script".  Caveat: many reports have correlated to resource contention outside of thunderbird (AV and the like). But we also need to understand if anything within thunderbird (autosync and gloda?) contribute to this problem in some cases. 

If we dont' get a clear understanding why the attachment bug happens, then we will have a harder time in the larger battle we need to wage against "unresponsive script", i.e. cases not related to attachments.
Comment 45 Wayne Mery (:wsmwk, NI for questions) 2010-12-30 07:55:16 PST
this probably is the canonical topic for "attachments": http://getsatisfaction.com/mozilla_messaging/topics/unresponsive_script_error-c17tu (a mixture of attachment and non-attachment reports ... 49 have this problem)

other notable reports...

caused by duplicated accounts in prefs.js: http://getsatisfaction.com/mozilla_messaging/topics/thunderbird_unresponsive_script_on_write_reply_forward

caused by Send Later add-on & attachments: http://getsatisfaction.com/mozilla_messaging/topics/long_hang_on_reply_to_emails_with_attachments

generic: http://getsatisfaction.com/mozilla_messaging/topics/unresponsive_js_script (14 have this problem)

all unresponsive script topics: http://getsatisfaction.com/mozilla_messaging/searches?query=script+AND+unresponsive&x=10&y=3&style=topics
Comment 46 Wayne Mery (:wsmwk, NI for questions) 2010-12-30 08:08:32 PST
bug list based on potential regression range cited in bug 493578 comment 7: https://bugzilla.mozilla.org/buglist.cgi?chfieldto=Now&chfield=[Bug%20creation]&query_format=advanced&chfieldfrom=2009-03-01&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&longdesc=unresponsive%20script&type0-0-0=nowords&value0-0-0=count%20counts&resolution=---&resolution=FIXED&resolution=INVALID&resolution=DUPLICATE&longdesc_type=substring&product=MailNews%20Core&product=Thunderbird  (which contains one bug fixed well prior to release of v3.0 and not related to attachments - Bug 480848 - unresponsive script warning starting thunderbird folderPane.js:845 caused by regression - excessive subfolder/folder IO activity on startup)
Comment 47 Wayne Mery (:wsmwk, NI for questions) 2010-12-30 09:42:42 PST
timeless' comment 18 comes closest to any attempt to assess this in a technical way. To wit
js calls a filepicker.
the file picker calls w32 which opens a window (the dialog) and pushes an event
loop.
timers fire looking for unresponsive scripts, they find one.

I don't see obvious candidates in core / firefox bugs to target/attach to - but it's harder to do so when don't know the origin of the issue

bugs mention "unresponsive script"  https://bugzilla.mozilla.org/buglist.cgi?field0-0-0=short_desc&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&type0-0-1=substring&field0-0-1=longdesc&resolution=---&resolution=FIXED&resolution=INVALID&chfieldto=Now&chfield=[Bug%20creation]&query_format=advanced&chfieldfrom=2009-01-01&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&value0-0-1=unresponsive%20script&type0-0-0=substring&value0-0-0=unresponsive%20script&product=Core&product=Firefox  

older FIXED bugs can obviously be ignored for issues that can still be reproduced on trunk - except bugs marked fixed in tracemonkey only
Comment 48 Zandr Milewski [:zandr] 2010-12-30 10:10:28 PST
OK, I think there's a core bug that causes the hang, at least on the Mac. (Which I think is just messed up UI event handling.)

I got into the same situation in Minefield yesterday when I had a file save dialog open and did something else that popped a Master Password sheet.

So it seems if you have a a filepicker open and something else causes a sheet to appear, you've now broken the UI.

Keeping an idle filepicker from causing the sheet to appear in the first place will avoid triggering this, but the hang itself appears to be a generic core bug.
Comment 49 Zandr Milewski [:zandr] 2010-12-30 10:12:13 PST
Oh, I see now that's bug 476541
Comment 50 timeless 2010-12-30 12:14:00 PST
there are currently three places where we get messed up by third party junk:

1. networking (LSPs and friends)
2. file pickers (shell extensions, and event loops)
3. printing (printer drivers)

The general fixes are:
1. move each of these out of process
2. switch to async apis

both steps are significant amounts of engineering effort.

Having the common dialogs running out of process would result in the individual dialogs not hanging when there's a slow script warning up. It doesn't automatically fix the consumer of the dialog (that should be stuck), but it would fix the complaint about the dialog.

If you want to be useful (vaguely, it won't be a major contribution), open Activity Monitor.app and use the Sample button to get a sample when you trigger this hang, save the log from the sample as *TEXT* and add an attachment of that saved *TEXT* (not "Rich Text") file.
Comment 51 Mitra Ardron 2011-01-01 02:47:15 PST
I notice that Bug #476541 doesn't look like its going to be fixed soon. 

I suggest again that until its fixed we shuld be shipping Thunderbird with  dom.max_script_run_time set to 0 and
dom.max_chrome_script_run_time set to 0 as suggested in Comment #13 

It really makes no sense to have an error checking action that causes more problems than it fixes! 

Since I set these too preferences, I haven't had any problems from this bug.
Comment 52 Wayne Mery (:wsmwk, NI for questions) 2011-02-07 08:06:30 PST
*** Bug 603645 has been marked as a duplicate of this bug. ***
Comment 53 Wayne Mery (:wsmwk, NI for questions) 2011-02-07 08:14:55 PST
*** Bug 625225 has been marked as a duplicate of this bug. ***
Comment 54 Wayne Mery (:wsmwk, NI for questions) 2011-02-07 08:21:13 PST
*** Bug 598260 has been marked as a duplicate of this bug. ***
Comment 55 Wayne Mery (:wsmwk, NI for questions) 2011-02-07 08:28:42 PST
*** Bug 564416 has been marked as a duplicate of this bug. ***
Comment 56 Wayne Mery (:wsmwk, NI for questions) 2011-02-20 13:11:54 PST
*** Bug 635565 has been marked as a duplicate of this bug. ***
Comment 57 Nomis101 2011-03-18 17:46:35 PDT
*** Bug 638510 has been marked as a duplicate of this bug. ***
Comment 58 Hari Krishna Dara 2011-03-24 15:38:07 PDT
I just hit this issue with probably a slightly different scenario that have already been reported. I am on Mac with Thunderbird 3.1.9. In my case, I downloaded an xpi separately and went into addons page to install the local addon, but had trouble finding it, so I switched to finder and the browser to see where I downloaded it, and got distracted. By the time I came back to Thunderbird, there was the "Unresponsive script" dialog. Selecting the file on the dialog didn't make it go away and I couldn't access any of the other windows (main window, addons window and the "Unresponsive script" window), so had to force close it.
Comment 59 Robert Goldman 2011-05-03 07:05:44 PDT
(In reply to comment #13)
> (In reply to comment #10)
> > I'd like to suggest a quick hack to REMOVE the unresponsive script check. I've
> > never ever seen it occur due to a real script timeout, only from failing to
> > respond to a dialog (e.g. most commonly a file attach when you realise you need
> > to do something to the file first). 
> 
> I've had some situations where this is not the case, so I'm hesitant to suggest
> removing the check outright.
> 
> On the other hand, there *are* ways to deactivate the script check now. AFAIK
> it applies to the entire Mozilla suite. (Verified Camino, Seamonkey, TB, FF.)
> Set dom.max_script_run_time to 0 to disable the check on most scripts. Set
> dom.max_chrome_script_run_time to 0 to disable the check on built-in or add-on
> scripts.

Which of these two parameters controls the timeout on the file picker?  That's the one that gets me.
Comment 60 Joe Sewell 2011-05-04 18:55:18 PDT
(In reply to comment #59)
> (In reply to comment #13)
> > (In reply to comment #10)
> > > I'd like to suggest a quick hack to REMOVE the unresponsive script check. I've
> > > never ever seen it occur due to a real script timeout, only from failing to
> > > respond to a dialog (e.g. most commonly a file attach when you realise you need
> > > to do something to the file first). 
> > 
> > I've had some situations where this is not the case, so I'm hesitant to suggest
> > removing the check outright.
> > 
> > On the other hand, there *are* ways to deactivate the script check now. AFAIK
> > it applies to the entire Mozilla suite. (Verified Camino, Seamonkey, TB, FF.)
> > Set dom.max_script_run_time to 0 to disable the check on most scripts. Set
> > dom.max_chrome_script_run_time to 0 to disable the check on built-in or add-on
> > scripts.
> 
> Which of these two parameters controls the timeout on the file picker?  That's
> the one that gets me.

If you'll reread what you quoted, you'll see that '''neither''' one deals with the file picker. It has no timeout, nor should it. The items I mentioned deal with disabling '''script''' timeouts. The second one deals with scripts found in add-ons and the Mozilla products themselves, while the first one deals with everything else. I'm not convinced that the blocked script is the one that puts up the file picker; if it is, then '''that''' should be noted as a distinct bug.

You asked for canceling '''all''' timeout checks. I gave you the means to do that with the existing setup.
Comment 61 zakwilcox+mozillabugzilla 2011-05-11 00:07:14 PDT
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'm not familiar with b.m.o bug tracking convention, but having two bugs open "to keep a visible bug in thunderbird component" (#16) seems misguided; this certainly is the same as bug 476541.
Comment 62 Wayne Mery (:wsmwk, NI for questions) 2011-05-11 06:17:03 PDT
(In reply to comment #61)
> 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.
a tempting idea. doing so of course risks leaving the user with a setting of 0 if something goes wrong after it gets set

> I'm not familiar with b.m.o bug tracking convention, but having two bugs
> open "to keep a visible bug in thunderbird component" (#16) seems misguided;
> this certainly is the same as bug 476541.
It's quite intentional and not without precedent - Thunderbird might develop it's own workarounds (and may have to if this core issue continues to be unaddressed), it aids thunderbird users who search bugzilla for open issues, etc.


there may be engineering effort, but this bug requires someone in core simply embracing the impact to thunderbird (making and using attachments is of course a common activity, which is only one type of trigger) and a commitment to addressing the issue.
Comment 63 Jim Porter (:squib) 2011-05-22 14:34:38 PDT
*** Bug 658895 has been marked as a duplicate of this bug. ***
Comment 64 Mark Banner (:standard8) 2011-06-09 06:44:36 PDT
We're not going to block on this issue, as we believe it is a core issue and needs resolving there. We will however be seeing if we can help drive the core issue forward.
Comment 65 Mitra Ardron 2011-06-10 01:18:17 PDT
Pity - since it
a: causes data loss
b: is very widely reported  and
c: has been a issue for over 2 years - so is unlikely to be fixed by whoever the "core" team are.

why can't TB just ship with the changed setting See Comment #13 and Comment #51.

I've been running with that setting for over a year now so I don't have this problem.
Comment 66 jb 2011-07-15 21:34:33 PDT
Adding my vote. Basically it seems like a simple deadlock problem. The Save As dialog or whatever can't complete until the unresponsive script dialog is clear, but the latter doesn't have focus.
Comment 67 Wayne Mery (:wsmwk, NI for questions) 2011-08-24 04:46:50 PDT
*** Bug 681453 has been marked as a duplicate of this bug. ***
Comment 68 Derek Williams 2011-08-24 14:56:04 PDT
I have this when browsing for attachment then navigating elsewhere for a while. Upon return to TB, the unresponsive script and the file browser are both there, error dialog only beeps, the file browser only acknowledges button press but they don't activate.
Comment 69 Derek Williams 2011-09-04 08:36:22 PDT
Created attachment 558152 [details]
"Warning: Unresponsive Script" dialog and File browser, 4 buttons, none work

In this scenario, the Stop Script and Continue buttons only beep, and don't activiate.  In the File Browser window, both Cancel and Open buttons highlight as if activated, but do not do anything. Force Quit is the only option when this happens.
Comment 70 Derek Williams 2011-09-04 08:39:46 PDT
Comment on attachment 558152 [details]
"Warning: Unresponsive Script" dialog and File browser, 4 buttons, none work

Now it's saying "Server not found" when I try to open the image I just uploaded to this page.
Comment 71 Derek Williams 2011-09-04 08:41:16 PDT
Created attachment 558153 [details]
"Server not found" when image access attempted

This is happening even though I am uploading the image and the comment to the same server.
Comment 72 Derek Williams 2011-09-04 08:49:35 PDT
fwiw the version of TB I am now using is 6.01, three versions after the one where this was first reported.

This bug has been around so long, I now deem it to be a Feature.  If it is indeed a feature, then I would very much like to know whose bright idea it was, so I can give them some feedback.
Comment 73 Wayne Mery (:wsmwk, NI for questions) 2011-09-24 19:58:34 PDT
*** Bug 668481 has been marked as a duplicate of this bug. ***
Comment 74 Virgil Dicu [:virgil] [QA] 2011-09-28 08:59:51 PDT
*** Bug 685573 has been marked as a duplicate of this bug. ***
Comment 75 Wally 2011-09-28 10:13:38 PDT
I've had a number of script stopped errors on ver 6. It seems to happen more often when I'm attaching files in Dropbox. About half the time, when the script window appears and I click "stop script", TB hangs completely and I have to kill it with the Task Manager.
Comment 76 Vincent Lefevre 2011-09-28 15:02:38 PDT
The Product should be changed to Core since this also affects Firefox.
Comment 77 Wally 2011-09-28 15:08:59 PDT
What is Core?
Comment 78 Vincent Lefevre 2011-09-28 15:10:48 PDT
(In reply to Wally from comment #77)
> What is Core?

See https://bugzilla.mozilla.org/describecomponents.cgi

And the platform should be changed to all/all (I get this problem under Linux).
Comment 79 Mitra Ardron 2011-09-28 19:16:10 PDT
I think the problem with mixing it with Firefox is that Firefox may very well have good reasons for wanting the default to stop errant scripts, while TB has very good reasons NOT to, as it can be data-loosing.  

See my comment #10, I dont think I ever had a case of a real unresponsive script. They have always been TB's built in dialogues with an unresponsive user. This doesn't happen on Firefox.
Comment 80 jb 2011-09-28 19:32:14 PDT
The problem as I see it isn't the stopping of scripts. Instead, it is the deadlock that occurs when the unresponsive-script dialog pops up when a file-open dialog is up. The easiest way to paper over this is to stop checking for unresponsive scripts when the latter dialog is up.
Comment 81 Vincent Lefevre 2011-09-28 23:34:15 PDT
In the case of Firefox, there are no scripts at all. The "Save As" dialog itself is the cause of the "Unresponsive script" dialog.
Comment 82 Mitra Ardron 2011-09-29 08:33:56 PDT
I'm 90% sure I've seen this dialog on Firefox, its not Firefox's internal scripts, its scripts on web pages that trigger it.  

Unresponsiveness might just come from the "Save As" ...
Comment 83 Vincent Lefevre 2011-09-29 08:46:36 PDT
This "Unresponsive script" dialog seems to occur with any page open. It occurs even with the "about:" page as the only open page. The only condition is that the "Save As" dialog must be open.
Comment 84 Wally 2011-09-29 10:11:30 PDT
OK. So I opened an email to someone, I clicked "attach" and went to a dropbox folder. I dragged the file into the upper right window where attachments go. A friend walked in and started talking to me. A minute or so later the "script not responding" box came up. Luckily I was able to cancel without the having to kill it with Task Mgr. So, I tried it again: 30 seconds later the script error appeared.
Comment 85 Wally 2011-09-29 10:13:32 PDT
Wild. While I was typing the msg above, the script msg came up again.
Script: resource:///modules/gloda/indexer.js:1414
Comment 86 Wayne Mery (:wsmwk, NI for questions) 2011-09-30 04:19:46 PDT
This was kept in product=Thunderbird for discoverability (by thunderbird reporters and triagers) and other reasons, including that we have one core bug blocking it (bug 476541). And as Mac-only bug because iirc there are other bugs covering windows issues. 

I am fairly confident there are bugs filed in core to cover the related core issues, and if not we can create them.
Comment 87 Wayne Mery (:wsmwk, NI for questions) 2011-09-30 04:41:59 PDT
for information which can help drive solution and triage see esp comment 46-50. (and comment 18)

if you can easily reproduce this, finding the regression range should be an easy way to contributing, whether you are on windows or Mac.

bug queries in my previous comments can be a starting point for someone to find related core bugs, and bug reporters on windows.  

and for bug reports for windows users - I thought we might keep windows and mac bug reports separate until the core issues were fully identified (not we don't have core windows bug yet) and until the desired solutions were better understood.  Further reason to keep them separate is perhaps Mac and windows have different workarounds and perhaps even different solutions. Detangling different problems that have been duped into a common bug in the future is a pain and can complicate the process to finding a solution - keeping them separate is easy.
Comment 88 Vincent Lefevre 2011-09-30 07:25:07 PDT
(In reply to Wayne Mery (:wsmwk) from comment #86)
> This was kept in product=Thunderbird for discoverability (by thunderbird
> reporters and triagers) and other reasons, including that we have one core
> bug blocking it (bug 476541). And as Mac-only bug because iirc there are
> other bugs covering windows issues.

I'm under Linux, and discoverability is also important for those who use Firefox only. So, I've de-dupped bug 685573. Since this bug 482811 is Mac-only (and blocked due to a bug in a Mac-only code), this cannot be the same bug as 685573.
Comment 89 Matthew Morley 2011-12-23 07:28:30 PST
Still affected by this.

Went to save a file from an email, but had to check something in Finder first, went back to Thunderbird and it was 'timed out' - couldn't click anything... Had to force closed and restart to save the file.
Comment 90 Adam Leeds 2012-02-19 13:44:05 PST
I am getting this bug still in the latest Firefox (Mac) 11.0 Beta. Are you sure this shouldn't be changed to Core rather than Thunderbird?

I've been reproducing it by trying to Save As... from a Print dialog.
Comment 91 Wayne Mery (:wsmwk, NI for questions) 2012-02-19 13:46:00 PST
(In reply to Adam Leeds from comment #90)
> I am getting this bug still in the latest Firefox (Mac) 11.0 Beta. Are you
> sure this shouldn't be changed to Core rather than Thunderbird?

quite sure. see whiteboard and dependencies please
Comment 92 Wayne Mery (:wsmwk, NI for questions) 2012-03-19 11:57:21 PDT
*** Bug 737096 has been marked as a duplicate of this bug. ***
Comment 93 Wayne Mery (:wsmwk, NI for questions) 2012-03-30 14:22:52 PDT
*** Bug 721716 has been marked as a duplicate of this bug. ***
Comment 94 Daniel Essin 2012-04-08 02:32:15 PDT
This is a really critical error. It makes we loose work and fixing errors that cause lost work should received immediate attention. There is nothing worse.
Comment 95 Nomis101 2012-04-08 02:40:21 PDT
My hope is, that Bug 729720 will fix this issue.
Comment 96 Joe Sewell 2012-04-08 17:18:01 PDT
It no longer applies to those of us who are still using PowerMacs, since Firefox/Thunderbird 3.x has reached EOS. Sad that such a "critical" bug has been tossed away for too long.
Comment 97 Derek Williams 2012-04-11 15:30:07 PDT
Created attachment 614199 [details]
THIS IS NOT FIXED!

No matter which button I click on, or which key I press, including Esc, Thunderbird just beeps. Force quit is the only way to escape from this.
Comment 98 Derek Williams 2012-04-11 15:32:47 PDT
Is anyone looking at this? Three years is a very long time to wait for a fix.
Comment 99 jb 2012-04-11 15:46:13 PDT
(In reply to Derek Williams from comment #98)
> Is anyone looking at this? Three years is a very long time to wait for a fix.

Somewhere along the(In reply to Derek Williams from comment #97)
> Created attachment 614199 [details]
> THIS IS NOT FIXED!
> 
> No matter which button I click on, or which key I press, including Esc,
> Thunderbird just beeps. Force quit is the only way to escape from this.

Somewhere along the line I think I went to Thunderbird->Preferences->Advanced->Config Editor and set dom.max_chrome_script_run_time and dom.max_script_run_time to 0. Try that.
Comment 100 Joe Sewell 2012-04-11 17:40:31 PDT
(In reply to Derek Williams from comment #98)
> Is anyone looking at this? Three years is a very long time to wait for a fix.

Note comment #95, Derek. It appears to be a design flaw. While the workaround in comment #99 may alleviate the problem, it also obliterates a useful, often necessary, function in the Mozilla product suite.

I'm so mad over this nonsense that I will start looking for a way to migrate away from Mozilla products.
Comment 101 Mitra Ardron 2012-04-11 17:58:18 PDT
I don't think there is much point complaining about this, Yes, its 100% repeatable, and data losing but it doesn't look like it will be fixed - Firefox needs it because its executing untrusted scripts, and Thunderbird developers blame the core suite, I don't think any of the developers are even on the Cc list for this bug ....
Comment 102 Matthias Versen [:Matti] 2012-04-22 17:39:18 PDT
*** Bug 747769 has been marked as a duplicate of this bug. ***
Comment 103 Derek Williams 2012-07-28 06:58:42 PDT
Created attachment 646849 [details]
Is hanging a feature or a bug of Thunderbird?

This has been around so long I am starting to believe the developers think it is something we need.  You type a long email, with carefully worked out arguments, honed and bullet pointed to perfection, then you go to attach a file.

Then you just wasted your life.  No buttons work.  You cannot open, cancel, save, save draft. Nothing.

But you CAN Force Quit and Lose Everything.  Hurrah!

Why does no-one at Mozilla HG think this is worth looking at?

Heartily sick of it.
Comment 104 Derek Williams 2012-07-28 07:00:08 PDT
PLEASE FIX THIS
Comment 105 Derek Williams 2012-07-28 07:00:44 PDT
LOOK AT ALL THE POSTINGS HERE AND NOTHING DONE. WHY DO WE BOTHER?
Comment 106 Mitra Ardron 2012-07-28 10:31:04 PDT
What is annoying is that in the abscense of any intention to fix it, a lesser evil (shipping TB with the preferences set to NOT check for unresponsive scripts) isn't prefered over this data-loss creating bug.  

Mark, Ludovic, can't one of you up this to a blocking bug, TB should not ship with data-losing, 100% repeatable bugs.  It would be much more preferable to ship with preferences set to not detect unresponsive scripts since a) it never happens (except for developers writing scripts) and b) even if you detect them its just going to crash TB anywy.
Comment 107 Steve Chessin 2012-07-31 20:22:01 PDT
It happened to me, too.  Thunderbird 14.0 on MacOS 10.5.8.
Comment 108 Siar Aneas 2012-08-02 08:26:24 PDT
The most annoying bug I know... It happened to nearly everyone I know. My Config (though it obviously doesn't matter) Mac OS 10.8. Thunderbinrd 14.0 with Extensions Lightning 1.6, Testpilot
I got rid of Firefox a couple of weeks ago - Thunderbird will be the next victim...
Comment 109 :Irving Reid (No longer working on Firefox) 2012-08-16 12:26:53 PDT
Created attachment 652521 [details] [diff] [review]
Disable slow chrome script warning on Mac OS

As a temporary workaround, disable the slow script warning for chrome scripts on Mac OS X. Full fix depends on bug 478073, bug 729720, and bug 783344.
Comment 110 Jonathan Protzenko [:protz] 2012-08-16 12:41:33 PDT
Irving, out of curiosity, http://www.brianbondy.com/blog/id/150 says « File pickers updated to be asynchronous on all platforms because it was needed for WinRT ». How does that relate to the work needed to fix this bug?
Comment 111 Mark Banner (:standard8) 2012-08-17 07:15:22 PDT
(In reply to Jonathan Protzenko [:protz] from comment #110)
> Irving, out of curiosity, http://www.brianbondy.com/blog/id/150 says « File
> pickers updated to be asynchronous on all platforms because it was needed
> for WinRT ». How does that relate to the work needed to fix this bug?

That would be part of it, but I believe it doesn't fix everything and we'd still need to do more work on our end for other sorts if dialogs. This is therefore a temporary improvement/workaround.
Comment 112 :Irving Reid (No longer working on Firefox) 2012-08-20 08:39:53 PDT
Checked in on trunk:

https://hg.mozilla.org/comm-central/rev/641fa621e376
Comment 113 :Irving Reid (No longer working on Firefox) 2012-08-21 10:38:15 PDT
Comment on attachment 652521 [details] [diff] [review]
Disable slow chrome script warning on Mac OS

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 478073
User impact if declined: TB on Mac locks up if file picker left open
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky): Low risk - only changes a default preference, and only applies to chrome scripts
String or UUID changes made by this patch: None
Comment 114 Mark Banner (:standard8) 2012-08-21 11:21:59 PDT
Comment on attachment 652521 [details] [diff] [review]
Disable slow chrome script warning on Mac OS

[Triage Comment]
You wanted the *-comm-* ones. I agree we should take this and see how it goes to minimise the pain.
Comment 116 Wayne Mery (:wsmwk, NI for questions) 2012-09-26 05:41:00 PDT
I have consolidated some Mac topics into https://getsatisfaction.com/mozilla_messaging/tags/bug_482811 aka https://getsatisfaction.com/mozilla_messaging/topics/unresponsive_script_error_when_selecting_attachment to cover this Mac-specific issue

thanks irving, mark and others for addressing this nagging problem.

Note You need to log in before you can comment on or make changes to this bug.