User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007102503 SeaMonkey/2.0a1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007102503 SeaMonkey/2.0a1pre Running SeaMonkey 2.0a1pre with xSidebar and the JSView extension installed: When visiting http://quotes.burntelectrons.org/browse SeaMonkey CPU usage jumps to 100%, a "busy script" message is received, and SeaMonkey has to be killed to get out of it. Here is my configuration: My configuration below: - - - User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007102503 SeaMonkey/2.0a1pre extensions Extensions(enabled: 11, disabled: 0) http://www.mozilla.org/"APNG Edit 1.0 http://console2.mozdev.org/index.html" Console² 0.3.8+ http://www.mozilla.org/projects/inspector/" DOM Inspector 1.9a9pre http://flashblock.mozdev.org Flashblock 1.3.7.1 http://greasemonkey.mozdev.org/" Greasemonkey 0.7.20070607.0 http://mozilla.doslash.org/infolister" InfoLister 0.9f.1 http://www.hacksrus.com/~ginda/venkman/" JavaScript Debugger0.9.87 http://forum.softwareblaze.com" JSView 1.4 http://menueditor.mozdev.org/" Menu Editor 1.2.3.3 http://wiki.mozilla.org/SeaMonkey:Debug_And_QA_UI" SeaMonkey Debug and QA UI 1.0pre http://xsidebar.mozdev.org/" xSidebar 1.0.3 "themes" Themes SeaMonkey Default Theme 1.0 SeaMonkey Modern 1.0 plugins" DivX Player Netscape Plugin DivX® Content Upload Plugin DivX® Web Player Java(TM) Platform SE 6 U3 Microsoft® DRM Mozilla Default Plug-in RealJukebox NS Plugin RealPlayer Version Plugin RealPlayer(tm) G2 LiveConnect-Enabled Plug-In (32-bit) Shockwave Flash Windows Media Player Plug-in Dynamic Link Library ------ The website displays fine in SeaMonkey 1.1.1 with JSView installed, the creator of JSView says that this bug occured in trunk Reproducible: Always Steps to Reproduce: 1. Visit http://quotes.burntelectrons.org with SeaMonkey 2.0a1pre + xSidebar + JSView 2. Click "browse" in the burntelectrons.org menu 3. Wait... Actual Results: CPU usage jumps to 100% A "busy script" message is displayed, but can't easily be killed. Expected Results: The website should display the funny Mozilla quotes ;-) I have reported this problem in the JSView forum here: http://forum.softwareblaze.com/viewtopic.php?t=182 - I'll copy the reply from the creator of JSView below: "The problem is actually with the latest SeaMonkey build. To make sure that all of the imported css are retrieved the jsview extension has to enter into a unusual loop that has caused some problems with a few browsers. In fact Firefox displayed the same problem until a patch was added to fix this bug. It appears that the same bug has found it's way into the latest SM build. Unfortunately the only thing that can be done at the moment is file a bug report (if one is not already filed) at bugzilla.mozilla.org and hope that they fix it soon. I'll see if I can find the previous bug report for Firefox. I'll post the link if I can find it." Ok, I finally found the link. This bug appeared prior to the FF2.0 release. https://bugzilla.mozilla.org/show_bug.cgi?id=337889 Basically what's happening is that the importedCSS method is calling itself from within the same method. cssarray.concat(this.importedCSS(rules[j].styleSheet)); Apparently in some browsers that causes an endless loop to occur. And unfortunately there's no other way to ensure that the extension has retrieved every imported stylesheet. Hopefully this should be sorted out before SM2.0 is officially released. Code: importedCSS: function(css) { var j; var cssarray = []; var rules = css.cssRules; for (j=0; j<rules.length; ++j) { if (rules[j].type==3) { cssarray.push(rules[j].styleSheet.href); cssarray = cssarray.concat(this.importedCSS(rules[j].styleSheet)); } else { break; } } return cssarray; }, So, it appears that the same problem was found and fixed on Firefox core : https://bugzilla.mozilla.org/show_bug.cgi?id=337889

Also happens in Firefox with JSView installed, visiting the URL and clicking Browse, though I haven't seen a crash. Unresponsive script dialog comes up and after ending the script Firefox becomes responsive again. This isn't really the same problem as bug 337889 which caused an immediate crash.

After clicking "Random" on the URL page and stopping the unresponsive script a few times I did crash. http://crash-stats.mozilla.com/report/index/72c1e07a-96a9-11dc-90c2-001a4bd43ed6 str: 1) install JSView https://addons.mozilla.org/en-US/firefox/addon/2076 2) Go to http://quotes.burntelectrons.org/browse 3) Click Random 4) when the unresponsive script dialog comes up, Click Stop Script 5) Click Random again 6) At this point several unresponsive script dialogs appear and clicking Stop Script crashes Minefield crash at nsRuleNode::WalkRuleTree

This is a regression since 2007100104, sorry, don't have time to narrow this down further atm.

I did some investigating and the recursive function isn't actually the cause of the unresponsive script dialog. The offending code is actually in the isCSSExternal method of jsview where it removes duplicates. //check for duplicate entries and remove them cssarray.sort(); for (var i=0; i<cssarray.length-1; ++i) { while (cssarray[i]==cssarray[i+1]) { cssarray.splice(i,1); } } (where cssarray has been created using the importedCSS method in comment 0) Some how cssarray has a bunch of null elements in it which end up at the end of the array after the sort operation and after removing all but one of them execution gets stuck in the while loop comparing the last element of cssarray (which is null) to a nonexistant element - the result of which is apparently true. I don't know how cssarray ends up having null elements in it but I did find a regression range for this behaviour: 2007102304 - No Unresponsive Script Dialog 2007102407 - Dialog appears bonsai link: http://tinyurl.com/22ajl7 What ever it is that's going on there is probably a separate bug from what is causing the crash. As for the actual crash, I noticed during testing that the STR I gave in comment 2 aren't always reliable. Part of the problem is that a large range of events cause JSView to refresh the list of styles, and only occasionally does it get stuck in the loop I mentioned above. I did notice that builds after 2007110212 are much easier to trigger the crash with and that in current builds it's less reproducible, but it does still crash with the yesterday's nightly: bp-9bf029c7-b1d8-11dc-942a-001a4bd43ef6 . The regression range above seems to implicate either Bug 398982 or Bug 397427 for breaking JSView but that probably just exposed the cause. Mats, can you shed any light on this?

The non-crash part of this is going to be fixed in bug 405818. Not sure about the crash part.

I guess fixing the null cssarray elements in bug 405818 will prevent JSView (the old 1.5 version) from entering it's endless loop under most circumstances and sidestep the crash. Boris, what would be needed to fix the crash independently of bug 405818? And do you think it would be worth trying to build a testcase where cssarray has two valid duplicate entries at the end - which would trigger the same endless loop but may or may not crash in the same way?

bz, do we care about the "crash part" of this bug, or should we just close it? Sounds like debugging the crash would be a painful archeological exercise.

I think marking this incomplete should be fine.