Mitra Ardron Reporter
	Description • 15 years ago

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.

	Mark Banner (:standard8)
	Comment 1 • 15 years ago

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.

	Wayne Mery (:wsmwk)
	Comment 2 • 15 years ago

bug 485398 a dup?

	Mitra Ardron Reporter
	Comment 3 • 15 years ago

Could be - though its Mac v. Unix and in bug 49538 comment 3 it suggests they are handled differently.

	WD
	Comment 4 • 14 years ago

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.

	jeffrey.glickman
	Comment 7 • 14 years ago

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.

	Jonathan Protzenko [:protz]
	Comment 8 • 14 years ago

Confirmed on Linux as well, this time with the "save all attachments" dialog.

	[:Aureliano Buendía]
	Comment 9 • 14 years ago

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

	Mitra Ardron Reporter
	Comment 10 • 14 years ago

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*

	Wayne Mery (:wsmwk)
	Comment 12 • 14 years ago

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

	Joe Sewell
	Comment 13 • 14 years ago

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

	Mitra Ardron Reporter
	Comment 14 • 14 years ago

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.

	Wayne Mery (:wsmwk)
	Comment 16 • 14 years ago

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

	Wayne Mery (:wsmwk)
	Comment 17 • 14 years ago

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

	timeless
	Comment 18 • 14 years ago

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.

	Wayne Mery (:wsmwk)
	Comment 19 • 14 years ago

(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?

	Joe Sewell
	Comment 22 • 14 years ago

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

	dave white
	Comment 23 • 14 years ago

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.

	Wayne Mery (:wsmwk)
	Comment 26 • 14 years ago

(In reply to comment #18)
> there shouldn't be any rocket science here.

indeed. 

my comment 16 query stinks for this bug. better is 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=FIXED&resolution=INVALID&resolution=DUPLICATE&resolution=WORKSFORME&classification=Client%20Software&classification=Components&chfieldto=Now&query_format=advanced&chfieldfrom=2007-01-01&short_desc_type=substring&longdesc=attach&type0-0-0=nowords&value0-0-0=count%20counts&field1-0-0=short_desc&longdesc_type=anywordssubstr

	u93378
	Comment 27 • 14 years ago

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

	Dmitry Panov
	Comment 29 • 14 years ago

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.

	Michael
	Comment 31 • 14 years ago

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

	Yansky
	Comment 34 • 14 years ago

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

	Joe Sewell
	Comment 35 • 14 years ago

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

	Yansky
	Comment 36 • 14 years ago

(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?

	Joe Sewell
	Comment 37 • 14 years ago

No, it could very well be the same bug, just a different view of it.

	Tom Phinney
	Comment 40 • 14 years ago

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.

	Chris Pepper
	Comment 41 • 14 years ago

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.

	Ludovic Hirlimann [:Usul]
	Comment 43 • 14 years ago

11 dups and counting -> Requesting blocking for 3.3

Wayne waht was your though when you added the qawanted keyword ?

	Wayne Mery (:wsmwk)
	Comment 44 • 14 years ago

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.

	Wayne Mery (:wsmwk)
	Comment 45 • 14 years ago

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

	Wayne Mery (:wsmwk)
	Comment 46 • 14 years ago

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)

	Wayne Mery (:wsmwk)
	Comment 47 • 14 years ago

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

	Zandr Milewski [:zandr]
	Comment 48 • 14 years ago

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.

	Zandr Milewski [:zandr]
	Comment 49 • 14 years ago

Oh, I see now that's bug 476541

	timeless
	Comment 50 • 14 years ago

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.

	Mitra Ardron Reporter
	Comment 51 • 14 years ago

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.

	Hari Krishna Dara
	Comment 58 • 13 years ago

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.

	u93378
	Comment 59 • 13 years ago

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

	Joe Sewell
	Comment 60 • 13 years ago

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

	zakwilcox+mozillabugzilla
	Comment 61 • 13 years ago

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.

	Wayne Mery (:wsmwk)
	Comment 62 • 13 years ago

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

	Mark Banner (:standard8)
	Comment 64 • 13 years ago

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.

	Mitra Ardron Reporter
	Comment 65 • 13 years ago

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.

	jb
	Comment 66 • 13 years ago

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.

	Derek Williams
	Comment 68 • 13 years ago

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.

	Derek Williams
	Comment 69 • 13 years ago

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.

	Derek Williams
	Comment 70 • 13 years ago

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.

	Derek Williams
	Comment 71 • 13 years ago

This is happening even though I am uploading the image and the comment to the same server.

	Derek Williams
	Comment 72 • 13 years ago

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.

	Wally
	Comment 75 • 13 years ago

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.

	Vincent Lefevre
	Comment 76 • 13 years ago

The Product should be changed to Core since this also affects Firefox.

	Wally
	Comment 77 • 13 years ago

What is Core?

	Vincent Lefevre
	Comment 78 • 13 years ago

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

	Mitra Ardron Reporter
	Comment 79 • 13 years ago

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.

	jb
	Comment 80 • 13 years ago

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.

	Vincent Lefevre
	Comment 81 • 13 years ago

In the case of Firefox, there are no scripts at all. The "Save As" dialog itself is the cause of the "Unresponsive script" dialog.

	Mitra Ardron Reporter
	Comment 82 • 13 years ago

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" ...

	Vincent Lefevre
	Comment 83 • 13 years ago

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.

	Wally
	Comment 84 • 13 years ago

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.

	Wally
	Comment 85 • 13 years ago

Wild. While I was typing the msg above, the script msg came up again.
Script: resource:///modules/gloda/indexer.js:1414

	Wayne Mery (:wsmwk)
	Comment 86 • 13 years ago

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.

	Wayne Mery (:wsmwk)
	Comment 87 • 13 years ago

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.

	Vincent Lefevre
	Comment 88 • 13 years ago

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

	Matthew Morley
	Comment 89 • 13 years ago

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.

	Adam Leeds
	Comment 90 • 12 years ago

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.

	Wayne Mery (:wsmwk)
	Comment 91 • 12 years ago

(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

	Daniel Essin
	Comment 94 • 12 years ago

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.

	Nomis101
	Comment 95 • 12 years ago

My hope is, that Bug 729720 will fix this issue.

	Joe Sewell
	Comment 96 • 12 years ago

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.

	Derek Williams
	Comment 97 • 12 years ago

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.

	Derek Williams
	Comment 98 • 12 years ago

Is anyone looking at this? Three years is a very long time to wait for a fix.

	jb
	Comment 99 • 12 years ago

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

	Joe Sewell
	Comment 100 • 12 years ago

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

	Mitra Ardron Reporter
	Comment 101 • 12 years ago

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

	Derek Williams
	Comment 103 • 12 years ago

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.

	Derek Williams
	Comment 104 • 12 years ago

PLEASE FIX THIS

	Derek Williams
	Comment 105 • 12 years ago

LOOK AT ALL THE POSTINGS HERE AND NOTHING DONE. WHY DO WE BOTHER?

	Mitra Ardron Reporter
	Comment 106 • 12 years ago

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.

	Steve Chessin
	Comment 107 • 12 years ago

It happened to me, too.  Thunderbird 14.0 on MacOS 10.5.8.

	Siar Aneas
	Comment 108 • 12 years ago

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

	:Irving Reid (No longer working on Firefox) Assignee
	Comment 109 • 12 years ago

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.

	Jonathan Protzenko [:protz]
	Comment 110 • 12 years ago

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?

	Mark Banner (:standard8)
	Comment 111 • 12 years ago

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

	:Irving Reid (No longer working on Firefox) Assignee
	Comment 112 • 12 years ago

Checked in on trunk:

https://hg.mozilla.org/comm-central/rev/641fa621e376

	:Irving Reid (No longer working on Firefox) Assignee
	Comment 113 • 12 years ago

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

	Mark Banner (:standard8)
	Comment 114 • 12 years ago

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.

	Mark Banner (:standard8)
	Comment 115 • 12 years ago

Checked in:

https://hg.mozilla.org/releases/comm-aurora/rev/90b0d23e8746
https://hg.mozilla.org/releases/comm-beta/rev/43bbc725bd6a

	Wayne Mery (:wsmwk)
	Comment 116 • 12 years ago

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.