Closed Bug 302333 Opened 16 years ago Closed 16 years ago
Inappropriate 'Unresponsive Script' warning
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.
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+ 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
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
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....
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.
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 on attachment 196824 [details] [diff] [review] Fix r+sr=bzbarsky
Fix checked into trunk.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
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 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+
Fix checked into MOZILLA_1_8_BRANCH.
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.
> 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.
You need to log in before you can comment on or make changes to this bug.