Inappropriate 'Unresponsive Script' warning

RESOLVED FIXED

Status

()

Core
DOM: Core & HTML
RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: walter sheets, Assigned: mrbkap)

Tracking

({fixed1.8})

Trunk
fixed1.8
Points:
---
Bug Flags:
blocking1.8b5 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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

12 years ago
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.

Comment 5

12 years ago
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.
The extension Flagfox http://flagfox.mozdev.org/ is keeping the alert from
appearing here :)
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]
This is still an issue
Assignee: nobody → general
Status: UNCONFIRMED → NEW
Component: General → JavaScript Engine
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → general
Hardware: PC → All
Version: unspecified → Trunk

Comment 9

12 years ago
not js engine, over to dom core.
Assignee: general → general
Component: JavaScript Engine → DOM: Core
QA Contact: general → ian

Comment 10

12 years ago
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

12 years ago
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

12 years ago
If it helps any, venkman should work fine in seamonkey builds....
(Reporter)

Comment 13

12 years ago
(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

12 years ago
(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

12 years ago
get script warning on 2005-09-14 trunk build, do not get script warning on
2005-09-15 trunk build.
(Assignee)

Comment 16

12 years ago
Created attachment 196824 [details] [diff] [review]
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.
Assignee: general → mrbkap
Status: NEW → ASSIGNED
Attachment #196824 - Flags: review?(bzbarsky)

Comment 17

12 years ago
Comment on attachment 196824 [details] [diff] [review]
Fix

r+sr=bzbarsky
Attachment #196824 - Flags: superreview+
Attachment #196824 - Flags: review?(bzbarsky)
Attachment #196824 - Flags: review+
(Assignee)

Comment 18

12 years ago
Fix checked into trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Updated

12 years ago
Flags: blocking1.8b5?
(Assignee)

Comment 19

12 years ago
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.
Attachment #196824 - Flags: approval1.8b5?

Comment 20

12 years ago
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.
Attachment #196824 - Flags: approval1.8b5? → approval1.8b5+

Updated

12 years ago
Flags: blocking1.8b5? → blocking1.8b5+
(Assignee)

Comment 21

12 years ago
Fix checked into MOZILLA_1_8_BRANCH.
Keywords: fixed1.8

Comment 22

12 years ago
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

12 years ago
> 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....
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.

Updated

9 years ago
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.