User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9b2pre) Gecko/2007112803 SeaMonkey/2.0a1pre equivalent to Firefox/2.0.0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9b2pre) Gecko/2007112803 SeaMonkey/2.0a1pre Whenever I open about:config, nothing happens for several seconds, then I get a warning about an unresponsive script. If I then right click on a preference to get a context menu, again nothing happens for several seconds, then I get another unresponsive script warning. After this happening several times, I can usually start working with the preferences without getting the warning. Reproducible: Always Steps to Reproduce: 1.Enter "about:config" in the location bar. 2. 3. Actual Results: Nothing happens for several seconds, then an "unresponsive script" warning appears. Expected Results: There should be no delays or unresponsive script warnings. I should just be able to edit preferences. To give you a time frame, I've noticed this for at least a couple of weeks. I have the same problem using two different profiles on two different computers.

I'll confirm this - on the branch. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12pre) Gecko/20080118 SeaMonkey/1.1.8pre I have only seen this occur when the jsview extension is installed. JsView http://forum.softwareblaze.com/viewtopic.php?t=2 Install SeaMonkey. Create new Profile. about:config Opens as expected. Install jsview. (You can use any version. The current 1.5, Dec. 2007, or go back down to 1.1.9, Sep. 2006. Doesn't matter.) about:config Unresponsive script warnings ensue. During this time of unresponsiveness, CPU usage hits 99%. This does not occur in the release version of SeaMonkey 1.1.7.

On the branch, this regressed between 2007-12-26-01 and 2007-12-27-00. I can also confirm that this occurs on the trunk. This is not solely limited to about:config, but can also be generated on particular webpages: http://www.seas-nve.dk/brochurer/.aspx There is a new development version of jsview, 2.0, available. 2.0 seems to resolve the issues on both the branch & the truck. unresposive error http://forum.softwareblaze.com/viewtopic.php?t=190 Nevertheless it is probably worth investigating to determine the changes that caused this to manifest itself on the branch.

Can you try a new nightly (Jan 19 or after)? There was a patch that landed between 26 and 27 that was backed out today.

Using jsview 1.5, unresponsive script persists on both todays branch & (yesterdays) trunk. I'll try again in a day or so & post back if there is a change. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12pre) Gecko/20080119 SeaMonkey/1.1.8pre Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008011816 SeaMonkey/2.0a1pre

OK, I see this on trunk. This regressed between seamonkey builds 2007-10-23-09-trunk and 2007-10-24-10-trunk (I see the same window both about:config and the URL in comment 2). The most relevant bug in that range seems to be bug 397427 (Make the "href" property of stylesheets reflect the original URI that was reflected to load the sheet.). I can't see the bug, but it probably made it on the branch (security). But unless there's some indication that something is going wrong on the gecko side, this is INVALID

Bug 397427 is also in the branch regression range given in comment 2. Andrew, how can I go about installing this extension (since it doesn't provide secure updates, I can't install it on trunk)? Alternately, would you be willing to breakpoint in nsJSContext::DOMOperationCallback down where it actually poses the dialog and see what the JS stack looks like?

Andrew, see comment 6?

The nsJSContext::DOMOperationCallback call seems to be originating from our own about:config code. Loading in a debug build, I get these in the console continuously while it's frozen: JavaScript strict warning: chrome://jsview/content/jsviewOverlay.js, line 576: reference to undefined property cssarray[i]

> how can I go about installing this extension (since it doesn't provide > secure updates, I can't install it on trunk)? extensions.checkUpdateSecurity This comes in handy too, extensions.checkCompatibility . http://kb.mozillazine.org/About:config_entries#Extensions..2A

> 2.0 seems to resolve the issues on both the branch & the truck. Could you ask the extension developers what they changed to do that? It looks like an object which they think is an array is actually a string, which makes their code do something weird... I'm not sure why that ends up happening yet.

cssarray is an array. It's a list of a stylesheets referenced from any loaded page, but then jsview does: cssarray.sort(); for (var i=0; i<cssarray.length-1; ++i) { while (cssarray[i]==cssarray[i+1]) { cssarray.splice(i,1); } } to remove duplicate entries. If the last two entries are duplicates, it's an infinite loop (with it continually referencing the element past the end of the array, which apparently caused the warning). oops. Before this bug showed up, the list was chrome://global/locale/intl.css chrome://global/skin/config.css chrome://global/skin/formatting.css After bug 397427, the list is the same on the first invocation and the second time, it's chrome://global/skin/config.css null null null So, buggy jsview code is definitely the cause of the hang, but having the null entries doesn't seem good... jsview is doing var rules = css.cssRules; for (var j=0; j<rules.length; ++j) { if (rules[j].type==3) { cssarray.push(rules[j].styleSheet.href); where |css| is some stylesheet. After 397427, rules[j].stylesheet is always null.

Aha! The null thing is the key here, and is definitely a bug, and a regression from bug 397427. It won't bite content, usually, though it can in some cases, but for chrome that sort of thing will happen all the time. Patch and regression test coming up.

David, this is a really easy review, and I'd like to get this into 1.8.1.12. Could you take a look at this soon?

Comment on attachment 298126 [details] [diff] [review] Fix. I swear I had this in my original patch... r+sr=dbaron

Comment on attachment 298126 [details] [diff] [review] Fix. I swear I had this in my original patch... Seeking trunk and branch approvals for this regression fix. This is very very safe.

It appears that the source of this bug has already been found but I thought I'd post some additional info related to it. I believe this bug is a duplicate of bug #404304 which causes the same unresponsive behavior in FF. For some reason when viewing a chrome page in the content window (about:config, about:neterror) the style sheets contain null as the href. This problem can occur with both embedded style sheets and imported style sheets. The infinite loop occurs in the importedCSS method in jsview 1.5. To avoid the loop in jsview 2.0 I changed that method (now named getImportedCSS) to check for null href values before pushing the style sheet into an array. However by ignoring the style sheets with null href values it prevents the extension from retrieving all of the style sheet urls. There is also an underlying problem in FF3 that is causing some strange behavior when viewing an about: page. In about:config there are 4 style sheets (1 embedded, 3 imported). When FF3 is finished loading about:config the jsview extension apparently retrieves all of the style sheet urls successfully. You can hover the mouse cursor over the jsview statusbar icon and it should display JS (1) SS (4). However when you click the statusbar icon the popup only displays 1 JS and 1 SS which means that the style sheet href's are no longer accessible. So it would appear that shortly after the onStateChange event is triggered in the progress listener with the STATE_IS_NETWORK flag all chrome style sheet href's are set to null (or at least are no longer accessible). In FF 2.0 there doesn't appear to be any problems with the chrome style sheet href's. When viewing about:config in FF 2.0 the jsview popup correctly displays 1 JS and 4 SS. I've listed a few links below that are related to this bug. A few links have been posted by other users who have encountered this bug on pages other than about:config. I have feeling that in those instances it was probably an iframe containing the about:neterror page that caused the unresponsive error, but that's only guess at the moment. http://forum.softwareblaze.com/viewtopic.php?t=190 http://forum.softwareblaze.com/viewtopic.php?t=183 http://forum.softwareblaze.com/viewtopic.php?t=182 https://bugzilla.mozilla.org/show_bug.cgi?id=404304 http://forum.softwareblaze.com/jsview/jsview2.0.xpi

> For some reason when viewing a chrome page in the content window > (about:config, about:neterror) the style sheets contain null as the href. Yeah, that happens when the rules of a cloned sheet (e.g. any chrome sheet) are accessed. The patch in this bug fixes that.

Should this be resolved now that it is checked in?

Checked in on trunk, with test.

Comment on attachment 298126 [details] [diff] [review] Fix. I swear I had this in my original patch... approved for 1.8.1.12, a=dveditz for release-drivers

Fixed on branch.

I have no hang when opening about:config using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/2008012820 Firefox/2.0.0.12

Comment on attachment 298126 [details] [diff] [review] Fix. I swear I had this in my original patch... caillon, please sign off together with bug #397427

Comment on attachment 298126 [details] [diff] [review] Fix. I swear I had this in my original patch... a=caillon for 1.8.0

Fixed in 1.8.0.15