Closed Bug 302333 Opened 18 years ago Closed 18 years ago

Inappropriate 'Unresponsive Script' warning


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

Not set





(Reporter: wsheets, Assigned: mrbkap)




(Keywords: fixed1.8)


(1 file)

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.
Seing this as well on XP
OS: Linux → All
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050726
Firefox/1.0+ ID:2005072606
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.
Odd. I see this on a clean profile and in safe mode, but not in my normal,
dirty, extension infested profile.
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.
The extension Flagfox is keeping the alert from
appearing here :)
This is still an issue
Assignee: nobody → general
Component: General → JavaScript Engine
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → general
Hardware: PC → All
Version: unspecified → Trunk
not js engine, over to dom core.
Assignee: general → general
Component: JavaScript Engine → DOM: Core
QA Contact: general → ian
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....
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.
If it helps any, venkman should work fine in seamonkey builds....
(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).
(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.
get script warning on 2005-09-14 trunk build, do not get script warning on
2005-09-15 trunk build.
Attached patch FixSplinter 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.
Assignee: general → mrbkap
Attachment #196824 - Flags: review?(bzbarsky)
Comment on attachment 196824 [details] [diff] [review]

Attachment #196824 - Flags: superreview+
Attachment #196824 - Flags: review?(bzbarsky)
Attachment #196824 - Flags: review+
Fix checked into trunk.
Closed: 18 years ago
Resolution: --- → FIXED
Flags: blocking1.8b5?
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.
Attachment #196824 - Flags: approval1.8b5?
Comment on attachment 196824 [details] [diff] [review]

this looks very low risk to me for the branch and I've seen this error before.
Attachment #196824 - Flags: approval1.8b5? → approval1.8b5+
Flags: blocking1.8b5? → blocking1.8b5+
Fix checked into MOZILLA_1_8_BRANCH.
Keywords: fixed1.8
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.
> 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....
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.
Component: DOM: Core → DOM: Core & HTML
QA Contact: ian → general
You need to log in before you can comment on or make changes to this bug.