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

RESOLVED FIXED

Status

()

Core
CSS Parsing and Computation
P3
normal
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: Andy Boze, Assigned: bz)

Tracking

({fixed1.8.0.15, regression, verified1.8.1.12})

Trunk
x86
All
fixed1.8.0.15, regression, verified1.8.1.12
Points:
---
Bug Flags:
blocking1.9 +
blocking1.8.1.12 +
wanted1.8.1.x +
blocking1.8.0.next +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

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

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

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

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

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

10 years ago
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
Assignee: general → nobody
Component: General → General
OS: Windows XP → All
Product: Mozilla Application Suite → Core
QA Contact: general → general
Version: unspecified → Trunk
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?
(Assignee)

Updated

10 years ago
Blocks: 397427

Comment 8

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

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

Comment 11

10 years ago
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.
Status: UNCONFIRMED → NEW
Component: General → Style System (CSS)
Ever confirmed: true
Flags: blocking1.9?
Flags: blocking1.8.1.12?
Keywords: regression
QA Contact: general → style-system
Summary: Opening about:config results in warning about unresponsive script → [FIX]Opening about:config results in warning about unresponsive script
Created attachment 298126 [details] [diff] [review]
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?
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #298126 - Flags: superreview?(dbaron)
Attachment #298126 - Flags: review?(dbaron)
Comment on attachment 298126 [details] [diff] [review]
Fix.  I swear I had this in my original patch...

r+sr=dbaron
Attachment #298126 - Flags: superreview?(dbaron)
Attachment #298126 - Flags: superreview+
Attachment #298126 - Flags: review?(dbaron)
Attachment #298126 - Flags: review+
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.
Attachment #298126 - Flags: approval1.9?
Attachment #298126 - Flags: approval1.8.1.12?

Comment 16

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

Updated

10 years ago
Attachment #298126 - Flags: approval1.9? → approval1.9+
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.12?
Flags: blocking1.8.1.12+

Comment 18

10 years ago
Should this be resolved now that it is checked in?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
Checked in on trunk, with test.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
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
Attachment #298126 - Flags: approval1.8.1.12? → approval1.8.1.12+
Fixed on branch.
Keywords: fixed1.8.1.12
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
Keywords: fixed1.8.1.12 → verified1.8.1.12

Comment 23

10 years ago
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
Attachment #298126 - Flags: approval1.8.0.15?

Comment 24

10 years ago
Created attachment 310236 [details] [diff] [review]
for your convenience: this applies cleanly on 1.8.0

Updated

10 years ago
Flags: blocking1.8.0.15+
Comment on attachment 298126 [details] [diff] [review]
Fix.  I swear I had this in my original patch...

a=caillon for 1.8.0
Attachment #298126 - Flags: approval1.8.0.15? → approval1.8.0.15+
Fixed in 1.8.0.15
Keywords: fixed1.8.0.15
You need to log in before you can comment on or make changes to this bug.