405818 - [FIX]Opening about:config results in warning about unresponsive script

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Andy Boze]

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.

Comment 1

[therube]

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.

Comment 2

[therube]

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.

Comment 3

[Andrew Schultz]

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.

Comment 4

[therube]

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

Comment 5

[Andrew Schultz]

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

Comment 6

[Boris Zbarsky [:bzbarsky]]

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?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Andrew, see comment 6?

Comment 8

[Andrew Schultz]

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]

Comment 9

[therube]

> 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

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[Andrew Schultz]

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.

Comment 12

[Boris Zbarsky [:bzbarsky]]

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.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix. I swear I had this in my original patch...

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 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 298126 [details] [diff] [review]
Fix.  I swear I had this in my original patch...

r+sr=dbaron

Comment 15

[Boris Zbarsky [:bzbarsky]]

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.

Comment 16

[sdb]

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

Comment 17

[Boris Zbarsky [:bzbarsky]]

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

Comment 18

[Mike Schroepfer]

Should this be resolved now that it is checked in?

Comment 19

[Boris Zbarsky [:bzbarsky]]

Checked in on trunk, with test.

Comment 20

[Daniel Veditz [:dveditz]]

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

Comment 21

[Boris Zbarsky [:bzbarsky]]

Fixed on branch.

Comment 22

[Samuel Sidler (old account; do not CC)]

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 23

[Alexander Sack]

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 24

[Alexander Sack]

Attachment: for your convenience: this applies cleanly on 1.8.0

Comment 25

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 298126 [details] [diff] [review]
Fix.  I swear I had this in my original patch...

a=caillon for 1.8.0

Comment 26

[Christopher Aillon (sabbatical, not receiving bugmail)]

Fixed in 1.8.0.15