Closed Bug 78089 Opened 23 years ago Closed 3 years ago

"A script on this page is causing mozilla to run slowly" message is too vague and badly worded

Categories

(Core :: DOM: Core & HTML, defect, P5)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: timeless, Assigned: timeless)

References

()

Details

(Keywords: intl, l12y, polish)

Attachments

(2 files, 1 obsolete file)

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.
Target Milestone: --- → Future
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.
Keywords: helpwanted
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.
QA Contact: desale → stummala
(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.
Priority: -- → P5
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.
Assignee: jst → timeless
Keywords: helpwanted
Target Milestone: Future → ---
Attached patch better patchSplinter Review
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
Flags: blocking1.8a2?
Keywords: intl
OS: Windows 2000 → All
Hardware: PC → All
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..."
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1? → blocking-aviary1.0RC1-
Attached image Similar error message screenshot (obsolete) —
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. ***
Blocks: 260392
Flags: blocking-aviary1.0?
Whiteboard: [hard-coded = non-localizable string]
Flags: blocking-aviary1.0? → blocking-aviary1.0-
The "polish" keyword also applies.
Attachment #82936 - Flags: superreview?(jst)
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
Whiteboard: [hard-coded = non-localizable string]
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 ]]  |
'--------------------------------------------------------------'
Keywords: polish
*** Bug 262378 has been marked as a duplicate of this bug. ***
QA Contact: stummala → ian
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...
Attachment #82936 - Flags: superreview?(jst)
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.
Summary: A script on this page is causing mozilla to run slowly. Do you want to abort the script? OK Cancel → "A script on this page is causing mozilla to run slowly" message is too vague and badly worded
Component: DOM: Core → DOM: Core & HTML
QA Contact: ian → general
Flags: wanted1.9.2?
Flags: wanted1.9.2?
Comment on attachment 157650 [details]
Similar error message screenshot

screen shot is not related to this bug
Attachment #157650 - Attachment is obsolete: true
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.

The current dialog for a slow page is pretty good. (The problem comment 45 points out should be fixed by Fission, but could be filed as a new bug I suppose.)

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

Attachment

General

Creator:
Created:
Updated:
Size: