302333 - Inappropriate 'Unresponsive Script' warning

Status: RESOLVED FIXED

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

Description

[walter sheets]

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 www.stamps.com
2.Click on any of the 'tabs' at the top
3.

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]

Seing this as well on XP

Comment 2

[Dave Townsend [:mossop]]

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

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

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]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050726 Firefox/1.0+
ID:2005072616

I'm seeing this too, but only in a clean profile.

Comment 6

[Ria Klaassen (not reading all bugmail)]

The extension Flagfox http://flagfox.mozdev.org/ is keeping the alert from
appearing here :)

Comment 7

[Dave Townsend [:mossop]]

Yes, for me adblock saves the day!
The only thing that adblock claims to be blocking is an image with this rather
odd, and ridiculously long url:

http://stampscom.112.2o7.net/b/ss/stampscom/1/G.9-Pd-R/s06844663219792?[AQB]&ndh=1&t=28/6/2005%2013%3A28%3A39%204%20-60&pageName=Home%20Page&g=http%3A//www.stamps.com/&v0=si10636452&cc=USD&s=1280x1024&c=32&j=1.3&v=Y&k=Y&bw=1280&bh=902&p=Mozilla%20Default%20Plug-in%3BQuickTime%20Plug-in%206.5.1%3BShockwave%20Flash%3BShockwave%20for%20Director%3BMicrosoft%20Office%202003%3BRealJukebox%20NS%20Plugin%3BRealPlayer%28tm%29%20G2%20LiveConnect-Enabled%20Plug-In%20%2832-bit%29%20%3BRealPlayer%20Version%20Plugin%3BJava%20Plug-in%3BMicrosoft%AE%20DRM%3BWindows%20Media%20Player%20Plug-in%20Dynamic%20Link%20Library%3B&[AQE]

Comment 8

[Dave Townsend [:mossop]]

This is still an issue

Comment 9

[Bob Clary [:bc] (inactive)]

not js engine, over to dom core.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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] (inactive)]

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. 
http://www.stamps.com/site/javascript/hbe.js

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 [:bzbarsky]]

If it helps any, venkman should work fine in seamonkey builds....

Comment 13

[walter sheets]

(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] (inactive)]

(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] (inactive)]

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) (inactive)]

Attachment: Fix

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 [:bzbarsky]]

Comment on attachment 196824 [details] [diff] [review]
Fix

r+sr=bzbarsky

Comment 18

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked into trunk.

Comment 19

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 196824 [details] [diff] [review]
Fix

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]

Comment on attachment 196824 [details] [diff] [review]
Fix

this looks very low risk to me for the branch and I've seen this error before.

Comment 21

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked into MOZILLA_1_8_BRANCH.

Comment 22

[eduboys]

Is this fix in the 1.5 release?  I'm still receiving this error at cbs.sportsline.com when I get realtime updates to my fantasy basketball stats.

Comment 23

[Boris Zbarsky [:bzbarsky]]

> Is this fix in the 1.5 release? 

Yes.

> I'm still receiving this error at cbs.sportsline.com 

They might actually have a script that takes a long time to run....

Comment 24

[Bill McGonigle (not currently reading bugmail; please contact directly)]

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.