Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 302333 - Inappropriate 'Unresponsive Script' warning
: Inappropriate 'Unresponsive Script' warning
: fixed1.8
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: -- normal with 2 votes (vote)
: ---
Assigned To: Blake Kaplan (:mrbkap)
: Jet Villegas (:jet)
Depends on:
  Show dependency treegraph
Reported: 2005-07-27 05:19 PDT by walter sheets
Modified: 2008-07-31 02:42 PDT (History)
10 users (show)
mscott: blocking1.8b5+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Fix (1.64 KB, patch)
2005-09-20 13:35 PDT, Blake Kaplan (:mrbkap)
bzbarsky: review+
bzbarsky: superreview+
mscott: approval1.8b5+
Details | Diff | Splinter Review

Description walter sheets 2005-07-27 05:19:56 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050727 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050727 Firefox/1.0+

Firefox(HEAD/20050727):  A warning dialog pops up when clicking on any of the
navigation tabs at the top of the webpage, saying 'Unresponsive Script'.
When I click on either 'Stop the script' or 'Proceed' the web page proceeds
to display correctly.  Thus, the warning seems inappropriate.

Reproducible: Always

Steps to Reproduce:
1.Go to
2.Click on any of the 'tabs' at the top

Actual Results:  
A warning dialog box pops up.

Expected Results:  
The new page should display with no warning dialog.

This does not happen in Firefox 1.0.6 release for Windows.
Comment 1 José Jeria 2005-07-27 06:00:48 PDT
Seing this as well on XP
Comment 2 Dave Townsend [:mossop] 2005-07-27 07:03:26 PDT
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050726
Firefox/1.0+ ID:2005072606
Comment 3 Steve England [:stevee] 2005-07-27 08:06:52 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050727
Firefox/1.0+ ID:2005072701
I see this too (with my current profile, and a new one).
The strange thing for me is that the warning pops up as soon as you click a
'tab' at the top of the page, yet I thought a script had to lock firefox for a
certain number of seconds before such an error msg would be generated.
Comment 4 Dave Townsend [:mossop] 2005-07-27 09:18:05 PDT
Odd. I see this on a clean profile and in safe mode, but not in my normal,
dirty, extension infested profile.
Comment 5 Adam Guthrie 2005-07-27 11:40:01 PDT
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050726 Firefox/1.0+

I'm seeing this too, but only in a clean profile.
Comment 6 Ria Klaassen (not reading all bugmail) 2005-07-27 12:24:10 PDT
The extension Flagfox is keeping the alert from
appearing here :)
Comment 8 Dave Townsend [:mossop] 2005-08-28 13:41:27 PDT
This is still an issue
Comment 9 Bob Clary [:bc:] 2005-08-28 13:56:54 PDT
not js engine, over to dom core.
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2005-09-19 20:47:14 PDT
Is this a problem with a current branch or trunk build?  Can someone who can
reproduce this create a minimal-ish testcase, possibly?  I can't seem to
reproduce this with a current Linux trunk build....
Comment 11 Bob Clary [:bc:] 2005-09-19 21:52:03 PDT
This is still a problem in at least branch builds on windows. I am trying to
figure out what is going on, but it lies in the hitbox ad code which is all
obfuscated and hard to figure out.

When you click a tab, it calls $x() which calls $v(). Unfortunately venkman
isn't available on the branch or trunk and trying to debug in 1.0.7 shows $v as
undefined in venkman although it is defined when not running in the debugger.
Comment 12 Boris Zbarsky [:bz] (still a bit busy) 2005-09-20 05:17:55 PDT
If it helps any, venkman should work fine in seamonkey builds....
Comment 13 walter sheets 2005-09-20 07:09:57 PDT
(In reply to comment #10)
> Is this a problem with a current branch or trunk build?...

I'm the original reporter of the bug, and I can no longer reproduce it in
firefox(HEAD) or seamonkey(HEAD).  FWIW I compile from CVS sources (on linux).
Comment 14 Bob Clary [:bc:] 2005-09-20 09:44:47 PDT
(In reply to comment #13)

I can confirm this is only a problem on the branch now. This works in Firefox
trunk but not in Firefox 1.4/Seamonkey 1.0a on windows xp. 

The warning appears regardless of the value of dom.max_script_run_time. I used
venkman in sm but didn't see what would cause this. There are "lots" of
conditional statements and uses of regexps, but nothing stood out to me. I'll
try to narrow the range where the trunk went from busted to working to see what
"fixed" this.
Comment 15 Bob Clary [:bc:] 2005-09-20 10:34:52 PDT
get script warning on 2005-09-14 trunk build, do not get script warning on
2005-09-15 trunk build.
Comment 16 Blake Kaplan (:mrbkap) 2005-09-20 13:35:03 PDT
Created attachment 196824 [details] [diff] [review]

The lesson to learn here is to always blame the UI ;-).

The problem that we are running into is that the GC that the branch callback
runs is collecting a not-yet-loaded image (probably the one that adblock was
happily denying). Destroying the image was sending state change events to the
docloader, and eventually to nsBrowserStatusFilter, which was running the UI
JS. When this had finished running, it was calling
nsJSContext::ScriptEvaluated, 0ing out the branch callback time, causing us
(when the stack unwound back into the branch callback) to think that the script
had been running for a really long time, so we displayed the warning.

This patch restores the branch callback time and count after the GC to protect
against this.
Comment 17 Boris Zbarsky [:bz] (still a bit busy) 2005-09-20 13:39:00 PDT
Comment on attachment 196824 [details] [diff] [review]

Comment 18 Blake Kaplan (:mrbkap) 2005-09-20 13:59:51 PDT
Fix checked into trunk.
Comment 19 Blake Kaplan (:mrbkap) 2005-09-20 14:00:55 PDT
Comment on attachment 196824 [details] [diff] [review]

This is a safe fix (it is a no-op in the general case) that makes the "slow
script warning" dialog more correct.
Comment 20 Scott MacGregor 2005-09-21 10:38:31 PDT
Comment on attachment 196824 [details] [diff] [review]

this looks very low risk to me for the branch and I've seen this error before.
Comment 21 Blake Kaplan (:mrbkap) 2005-09-21 11:02:13 PDT
Fix checked into MOZILLA_1_8_BRANCH.
Comment 22 eduboys 2005-11-30 16:53:17 PST
Is this fix in the 1.5 release?  I'm still receiving this error at when I get realtime updates to my fantasy basketball stats.
Comment 23 Boris Zbarsky [:bz] (still a bit busy) 2005-11-30 21:34:05 PST
> Is this fix in the 1.5 release? 


> I'm still receiving this error at 

They might actually have a script that takes a long time to run....
Comment 24 Bill McGonigle (not currently reading bugmail; please contact directly) 2005-12-11 13:52:57 PST
This can also occur when Firefox is just plain busy.  I'll often open a dozen links from my RSS reader before Firefox can finish rendering each one.  I get the aforementioned error on maybe a quarter of the windows in this case.  This is on a 1.2GHz iBook G4.  I'm running NoScript, so the responsiveness problem isn't from 3rd-party scripts.  

For my own use I just set dom.max_script_run_time to a larger value.  But conceptually, the expectation of how fast a page should take to render should at least be a function of how busy the browser is, if not accounting for system load in addition.

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