Script warning <p class="confused">What language is the script, and how do I know who posted the dialog? (Please at least blame JavaScript) </p> A script on ??this?? page is causing mozilla to run slowly. <p class="confused">I have lots of pages, perhaps even frames, would you mind telling me the name of the page? it'd be very useful for debugging purposes.</p> <p class="future">On OS X, we could attach the dialog to the actual frame/window so I could actually know what page was messing up, and then i'd just click the stop button like a normal user.</p> <p class="ot">i didn't notice. Or i did. whichever. Either this was clear to me because i was paying attention, or i had forgotten all about it and really didn't notice.</p> If it continues to run, your computer may become unresponsive. <p class="ot surprised angrered">Excuse me? Why would this make my computer unresponsive? Are you crazy? What does this really mean?</p> Do you want to abort the script? <p>Probably, let me see, what are my choices?</p> [Ok] [Cancel] Whoops, I was looking for Yes and perhaps No. Personally, i'd like to be able to copy the url so i can file a bug about the page. In this case, it's "System Crash" http://www.cyberarmy.com/cra [i can't see the rest, and mozilla is stuck] don't worry, I visited that page because it was referenced by a bugzilla bug report.

The reason this dialog pops up is that an infinite (or extremely long running loop) is currently executing in mozilla, this dialog lets you stop the execution of the script. Heh, the text in that dialog is the same as it is in IE's version of the same dialog. IE does have "Yes" and "No" in it's dialog, but currently (or at least not at the time when the dialog opening code was written) there's no API for the DOM code to open up a dialog with "Yes" and "No" buttons (w/o providing the dialog code too, which is not acceptable). Any suggestions to improvments are, as always, welcome, but this is not critical at this point. Marking Future for now.

I'm not at all sad that you can't use `Yes' and `No', because `Yes' and `No' are horrible labels for alert button text. Moral of the story: Don't copy Microsoft on UI details, they often get it wrong. But I'm also not surprised that Timeless found the alert text distinctly unhelpful, being copied as it was straight from Internet Explorer. Moral of the story: Don't copy Microsoft on UI details, they often get it wrong. A refinement of my suggestion in bug 13350 ... +----------------------------------------------------------+ |::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| +----------------------------------------------------------+ | . A script in this document has been running for more | | /!\ than 30 seconds. This may mean that it has stalled. | | """ [http://bugzilla.mozilla.org/query.cgi ] | | | | Do you want to continue running this script? | | | | [/] _Ask me again if the script doesn't finish soon | | | | ( Stop ) ((Continue)) | +----------------------------------------------------------+ I think this design addresses all of Timeless's concerns, except that it doesn't provide the language the script was written in -- and I *really* don't think we need to do that, that's what View Source is for.

It's an improvement. +----------------------------------------------------------+ |: JavaScript :::::::::::::::::::::::::::::::::::::::::::::| +----------------------------------------------------------+ | . A script has been running for more than 30 seconds. | | /!\ This may mean that it stalled. | | """ | | |> Do you want to continue running this script? | - - | Script name: [ (from ID/name tag) ] | | Script origin: [ http://mozilla.org/bzQuery.js ] | | Document: [http://bugzilla.mozilla.org/query.cgi ] | | [/] _Ask me again if it doesn't finish soon. | - - | (( Yes )) ( No ) | +----------------------------------------------------------+ Stop doesn't work as an answer to what is still a yes/no question. mpt proposed Cancel when I pointed out that Stop wasn't a good answer to our yes/no question. I can't get Cancel or Continue to be answers to questions either, but ... <mpt> dmose: Microsoft used to recommend that you phrase dialogs so that you could use `Yes' and `No'. Then they realized that people don't read the alerts, so now they recommend that you *don't* use `Yes' and `No'.

Updating QA contact to Shivakiran Tummala.

(these comments go w/the screenshot I just submitted) I just got this error message and found it very techie and confusing from the eyes of an ESPN visitor, say like my dad. Suggestion: -Change "mozilla" to "your browser" -Change "abort the script" be changed to "stop the script from running"

did not see the problem when visited espn.com, changing the priority.

Bug 13350 Comment #86 Created an attachment (id=82836) stage 1 fix for the warning dialog Bug 13350 Comment 41 suggests that we fix the dialog which comes up occasionally. Bug 13350 Comment #87 When we do catch a script running too long, we need to decide what to do, the options i'm thinking of are: A. stop this script now (it's run too long) B. stop this script now, and stop other scripts when they run too long C. continue this script, but prompt me the next time a (or this) script runs too long D. let the script run forever imo a good system should allow embedders to decide which of these steps to take without showing the options to the user and without hacking the c++ source files... bc suggests that if i'm forced to drop one of A or B i should drop A, his reasoning is that if a user is attacked by a DOS page then the user needs to be able to stop everything (B), whereas A won't help. [mpt suggested that I flip a coin to pick, so after mpt ducked the coin, I relied on bc] The patch I attached doesn't handle B or D because I haven't figured out how to leave a note reminding mozilla that the user made a decission for the script. [Part of this is that we keep running into serious architecture flaws in the prompt service. I'll try and get an improved flavor for 1.1 or 1.2 but that won't help us now] So anyways... shaver suggested that I set private data somewhere to remember what the user said about the script. It turns out that I can't set it on the script itself because the script isn't a jsobject. I might be able to ask the js context for the js object that owns the script, or I might have to store my data on the context. I'm looking for advice from jst or rginda or anyone who can offer it. Anyways a bit about this patch 1. it makes the errors localizable 2. it removes 'abort' from the message (mpt has a rant about abort somewhere) 3. it replaces OK/Cancel (which don't make sense as answers to a Yes/No question) with Continue/Stop (which also don't make sense, but which at least have some mapping -- this is a continuous debate between mpt and I) 4. it makes it easier for embedders to decide that error cases should stop scripts instead of continuing them forever [this point is negotiable, esp the wording] 5. it shows my thoughts about how to store the remember flag. As for the order of Continue/Stop, that's another issue w/ the prompt service api. The code I'm proposing minus all of the commented out/noop changes is a straight exchange. If we really want the other order, either we should fix the prompt service to handle order for us, or we will have to change the return !ret; line at the end of the code. -- sorry all, i couldn't find this bug. anyways the patch i attached is a first step. all of the advanced stuff will require more work and can be done later.

unfortunately continue forever is a bad idea... i'll have to do something about that

*** Bug 186279 has been marked as a duplicate of this bug. ***

I'm getting this in mail/news, when I try sending to an invalid address (like with a newsgroup name in a "To:" field instead of a "Newsgroup:" field; see bug 221269), and get the compose window back up again, and try to use the pulldown menu to change a "To:" field to a "Newsgroup:" field. It makes Mozilla appear to hang for a while, and then the dialog comes up. Apparently there's some internal script with an infinite loop.

I'm using 2003100204 with Win2000 and have something similar in the mail client: After writing an email with an pdf attachement, I clicked into the first edit field for mail adresses, while 'TO' was activited to the left. This caused the start of the loop. After answering 'OK', the (waiting-)loop started again. After waiting a third time and breaking it with 'OK' mail was usable again. To me it looked like there is an endless loop, while searching for the pattern null or "", to identify an mail address

I got exactly the same as commenters #11 & #12. I'm currently using: Mozilla 1.6a Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031004 When I red the thread on this bug since earlier year 2001, I'm very uppset by the comment of Johnny Stenback: "IE do so, so why do you complain?" ??? WHAT? Since when it is a policy at Mozilla.org to copy bullshiting from IE??? I'm completely agree with the 1st comment of the thread. At the time it was posted, I wasn't familiar enough with bugzilla to post something, but as the dialog box still arrives inappropriately after two more years of nightly builds, I may add my angry to this. WHAT DOES THIS BOX MEAN? You want us to help you, OK. You already have that. But be more precise on this glitch box. -- In which window or page or frame does this script run? Is this really an external script (page or url red) or inside javascript coding? -- If I only open the mail window and click in field "TO:", SOMETIMES everything hangs in Mozilla, and after a few seconds (~20), this box appears. -- If the famous script is related to mail posting, how may I know if it is helpful for me to stop or continue??? -- If this happens to me during a bank transaction, how may I know if it is helpful for me to stop or continue??? Without more specific information on this, I wont declare this glitch "trivial". Regards, Mikee.

Mike, I'm sorry if my earlier comment upset you, I did not intend to upset anyone with that comment. And I never meant to say anything that suggested that we're in any way tied to the current text in that dialog box. The fact that you're apparently getting this dialog when you're using mail is something that should be investigated and fixed, this dialog should never show up when any Mozilla UI code runs, if it does, that's a problem with the UI code. I'm very open to improving this dialog, but the bottom line is, users should only see this if they stumble across either a malicious site that attempts to lock up a users computer, or if a website is poorly developed and executes way too much script w/o interruptions. So given that, it's IMO not necessary to get too detailed in this dialog, if we did that most users wouldn't understand this dialog any better than they do now. This dialog is not intended to be a website debugging tool for developers.

*** Bug 230560 has been marked as a duplicate of this bug. ***

Even though it's a yes/no question, using verbs as answers is a good idea. It's been recommended by Apple's Human Interface Guidelines for years, and according to dmose Microsoft has finally figured this out too. From Apple's current HIG: "Button names should correspond to the action the user performs when pressing the button—for example, Erase, Save, or Delete. The rightmost button in the dialog is the button that confirms the alert message text. The rightmost button is usually, but not always, the default button." For example: "Do you want to save changes to this document before closing?" Fine print: "If you don't save, your changes will be lost." [_Don't_Save_] [_Cancel_] [_Save_] Much better than Yes/No, since the user doesn't have to differentiate between "Do you want to save changes to this document before closing?" and "Do you want to close this document without saving changes?". I rather like "Continue" and "Abort" in this case. Cancel has the connotation of changing your mind and not proceeding with something you were about to do, while Abort has the connotation of taking a new action to stop something already in progress. Especially since the script with the infinite loop may not have been user-initiated, I think stopping it should be seen as taking action (Abort), rather than not taking action (Cancel).

Apart from all other concerns, the message needs to be localizable, not hardcoded in English.

I also vote for this being made localizable ASAP. epecially because bug 13350 has been fixed, this dialog pops up more often now. Using "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-DE; rv:1.7) Gecko/20040614 Firefox/0.9" here, with at least one English dialog we can't do anything about ;) Would also be nice if it would make it for Firefox 1.0

Please add the l12y keyword for hardcoded strings.

As pointed out in bug 248151, there's a typo in the alert. Mozilla is a proper noun and should be written with a leading capital letter: The alert should read "....is causing Mozilla to run slowly..."

I am seeing a similar dialog when loading http://www.amena.com/ : "A script in this movie is causing Macromedia Flash Player 7 to run slowly. If it continues to run, your computer may become unresponsive. Do you want to abort the script?" The only button shown is "OK" - there is no "Cancel" or "No" button - so the whole dialog does not make any sense. This appears in both FF 0.9.3 and Mozilla 1.8a3 (both Linux). Is this related to this bug here?

No, that's a flash plugin dialog, nothing to do with this bug.

Bug 249086 changed the buttons to Yes/No.

*** Bug 259128 has been marked as a duplicate of this bug. ***

*** Bug 260009 has been marked as a duplicate of this bug. ***

The "polish" keyword also applies.

FWIW, the patch on bug 145523 (which has been committed) fixes quite a few things related to this bug. It doesn't implement mpt's exact suggestion, but it fixes the terrible OK/Cancel buttons, removes the hardcoded browser name, and removes the reference to the exact language of the script. I'd suggest marking this bug a dup of 145523, unless someone wants to keep this open to implement mpt's 'ask me again' checkbox, or feels passionately about (Stop)((Continue)) instead of (Stop Script)((Continue)). Also, cleaning up the whiteboard, since the string is no longer hardcoded. Relevant text from the patch, for reference: +KillScriptTitle=Warning: Unresponsive script +KillScriptMessage=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. +StopScriptButton=Stop script +WaitForScriptButton=Continue

I have been happily running Firefox for over a year, in conjunction with IE (for those pages which would not allow firefox) Tonight I tried to download the Google Toolbar and my problems started. I uninstalled the Google Toolbar and uninstalled Firefox but the Script Warning continued. I have Windows ME and 20 gig. I have again had to uninstall firefox.

I have been happily running Firefox for over a year, in conjunction with IE (for those pages which would not allow firefox) Tonight I tried to download the Google Toolbar and my problems started. I uninstalled the Google Toolbar and uninstalled and reinstalled Firefox twice. I had to reboot each time I tried to open Firefox - no matter what options were given, my pc locked up. I have Windows ME and 20 gig. I have again had to uninstall firefox.

Bugzilla isn't a support forum. This is: http://forums.mozillazine.org/viewforum.php?f=38

Is there a separate bug entry for "javascript on page [foo] is never caught by DOMBranchCallback and the browser hangs" or are they included here?

I see this same problem, when using google maps that have complicated lines. In my case there is no right answer. Pressing "OK" does not cancel the script. Pressing "CANCEL" does not cancel -- the message coms up again and again and again and again with no break. How about: +----------------------------------------------------------+ |::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| +----------------------------------------------------------+ | . A script in this document has been running without | | /!\ pause for more than 30 seconds. It has used 64M | | """ of memory. | | Do you want to continue running this script? | | | | [Keep running for 30 more seconds] | | [Stop it now] [Leave it running indefinitely] | +----------------------------------------------------------+ My test environment: http://www.obviously.com/gis/gpx_loader.html

I've experienced this "script running slowly" many times with Mozilla, though in my case it's always popped up after I closed Mozilla — or should I say, told Mozilla to close. I think my run-in with this problem comes from the Wired site, since I had it in my Tech Group groupmarks, and since I deleted it from this groupmark, I haven't seen the warning/error message again. Since I had six links in my Tech Group set, I never could really figure out who was dragging me down, and wished every time I saw the warning that it gave me more information, such as which page contained the stalling script. Since I was getting the warning after telling Mozilla to close, perhaps it isn't possible to tell me which page was dragging things down, but such information would be almost infinitely useful.

*** Bug 328190 has been marked as a duplicate of this bug. ***

(In reply to comment #0) > Personally, i'd like to be able to copy the url so i can file a bug about the > page. In this case, it's "System Crash" http://www.cyberarmy.com/cra [i can't > see the rest, and mozilla is stuck] don't worry, I visited that page because > it was referenced by a bugzilla bug report. I think that this issue is now handled nicely by the "Report broken website ..." tool. So the current dialog looks like this: .--------------------------------------------------------------. | Warning: Unresponsive script | +--------------------------------------------------------------+ | 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. | | | | [ Stop ] [[ Continue ]] | '--------------------------------------------------------------' It still suffers from the problem that it lets (and by default encourages) users to get into a position where they might be stuck in an infinite loop. It also requires that users understand what a "script" is, which seems wrongminded. Folding in some of the aspects of the original MPT suggestion: .--------------------------------------------------------------. | Warning: Unresponsive page | +--------------------------------------------------------------+ | This page contains a function that is not responding, which | | may cause your system to run slowly if it is allowed to | | continue. | | | | Do you want to stop this function? | | | | [x] Ask me again if it does not respond soon | | | | [ Stop ] [[ Continue ]] | '--------------------------------------------------------------'

*** Bug 262378 has been marked as a duplicate of this bug. ***

Additionaly, an Error should be echoed in the Javascript Console, listing the URL and if possible line number.

(In reply to comment #37) > Additionaly, an Error should be echoed in the Javascript Console, listing the > URL and if possible line number. bug 257646

Comment on attachment 82936 [details] [diff] [review] better patch This isn't needed any more is it? If it is, please re-request sr on this patch, or an updated one...

I am experiencing this bug or something very similar when using a certain laptop and browsing documentation at www.cisco.com. This particular laptop is W2K, with seamonkey and an autoproxy server. When I use IE for the same page it does not produce this error. Also this error does not occur 100% of the time either. I just wanted to post this to make the developers aware. I will try to gather more details the next time it happens.

I experience the problem, too. I get the message - interestingly even with no page loaded (firefox started with about:blank) - but I have no clue where the problem's origin is. Due to the fact that it pops up even with no page loaded at all, I suspect some extension to run amok, but I don't want to uninstall 'em all one by one - resulting in now way to fix it. A somewhat more informative error message would solve that. The problem I experience seems to be completely unrelated to the page(s) currently loaded (one more pointer to an extension ...). Maybe some kind of object tree like in Java exception console messages would be a nice & helpful addition ... -FH

I also have a problem with this message box popping up. it usually happens when I have 50 or 60 tabs open for a couple of weeks, although I have seen it with fewer tabs. it would be very handy to have it reference a url or a particular tab so that I can close the offending one. Perhaps this could be in a "Details" button or a drop down at the bottom of the box. Also it seems to come up multiple times so I am not confident that it properly ends the offending script, perhaps it should not allow the script to restart, if that is the problem.

Comment on attachment 157650 [details] Similar error message screenshot screen shot is not related to this bug

A lot of pages on Microsoft hang SeaMonkey with unresponsive script errors. You can't tell it to ignore since the scripts are all named differently on each page from what I've seen. So this makes it a hassle. Below is an example page that will cause SeaMonkey 2.x to display this warning. URL: http://support.microsoft.com/?kbid=2530548 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: http://support.microsoft.com/common/script/gsfx/kb.js?43:1301 Perhaps the way around this is to allow a user to set a preference that says, if a script doesn't respond in X amount of time, to just kill it. This would be a user setting so that the person would have to activate this feature to auto kill endlessly running scripts. Perhaps in this manner under the "Advanced / Scripts & Plugins" area an item that says this: Kill scripts if they do not respond after [DROP DOWN OF TIMES, STARTING AT 60 AND GOING UP FROM THERE IN INCREMENTS OF 30] seconds.

I got a different message across the top of the window saying that the page was making the browser run slow. However, it seems to be blaming the closest victim in a competition for resources amongst all processes.