Scrollbars are not being update using dss.enabled




CSS Parsing and Computation
8 years ago
8 years ago


(Reporter: ShareBird, Assigned: bz)


({fixed1.9.0.19, regression})

1.9.2 Branch
fixed1.9.0.19, regression

Firefox Tracking Flags

(status1.9.2 .2-fixed, status1.9.1 .9-fixed)



(2 attachments)



8 years ago
I've written a small extension to make possible to switch themes without a restart. 
It basically uses the dss.enabled feature and the reloadChrome method from nsIChromeRegistry:

The extension is available at:

With Namoroka builds after 2010-02-13 the scrollbars are not being updated as they should and have done until build 2010-02-12.
This issues is only present on Namoroka, not on Minefield.

The pushlog range of this regression is:

So it seems it is a regression from Bug 535806
Ah, I bet the chrome registry uses a case-insensitive CSSLoader (which means that it was pretty broken to start with in terms of its stylesheet reloading).
Created attachment 427611 [details] [diff] [review]
Proposed fix
Assignee: nobody → bzbarsky
Attachment #427611 - Flags: review?(dbaron)
Should probably land this on older branches too, right?
Blocks: 535806
Component: General → Style System (CSS)
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → style-system
Hardware: x86 → All
Version: 3.6 Branch → 1.9.2 Branch
Comment on attachment 427611 [details] [diff] [review]
Proposed fix

>   static void LoadSheet(nsIURI* aURI, nsCOMPtr<nsICSSStyleSheet> &aSheet,
>-                        PRBool aEnableUnsafeRules);
>+                        PRBool aEnableUnsafeRules,
>+                        PRBool aUseCaseSensitiveLoader = PR_FALSE);

Can you avoid the default value and make all callers pass the boolean explicitly?

Attachment #427611 - Flags: review?(dbaron) → review+
Created attachment 427637 [details] [diff] [review]
With that change

Requesting branch approvals.  This patch is not necessary (or even possible) on trunk.
Attachment #427637 - Flags: approval1.9.2.2?
Attachment #427637 - Flags: approval1.9.1.9?
Attachment #427637 - Flags: approval1.9.0.19?
Comment on attachment 427637 [details] [diff] [review]
With that change

a=beltzner for all branches, thanks, bz!
Attachment #427637 - Flags: approval1.9.2.2?
Attachment #427637 - Flags: approval1.9.2.2+
Attachment #427637 - Flags: approval1.9.1.9?
Attachment #427637 - Flags: approval1.9.1.9+
Attachment #427637 - Flags: approval1.9.0.19?
Attachment #427637 - Flags: approval1.9.0.19+

Checked into CVS:
Checking in chrome/src/nsChromeRegistry.cpp;
/cvsroot/mozilla/chrome/src/nsChromeRegistry.cpp,v  <--  nsChromeRegistry.cpp
new revision: 1.370; previous revision: 1.369
Checking in layout/style/nsLayoutStylesheetCache.h;
/cvsroot/mozilla/layout/style/nsLayoutStylesheetCache.h,v  <--  nsLayoutStylesheetCache.h
new revision: 1.9; previous revision: 1.8
Checking in layout/style/nsLayoutStylesheetCache.cpp;
/cvsroot/mozilla/layout/style/nsLayoutStylesheetCache.cpp,v  <--  nsLayoutStylesheetCache.cpp
new revision: 1.15; previous revision: 1.14
Last Resolved: 8 years ago
status1.9.1: --- → .9-fixed
status1.9.2: --- → .2-fixed
Keywords: fixed1.9.0.19
Resolution: --- → FIXED

Comment 8

8 years ago

This looks like it was made on a relbranch and not the default branch, right?
Er... yes.  I have no idea how that happened, but it's wrong.  Fixing now.
Backed out from the relbranch:

Pushed to default branch:

Comment 11

8 years ago
Thank you Boris and Mike!
Is it possible to land this patch also on comm-1.9.1 branch?
I checked this in on mozilla-1.9.1.  I would think that comm-1.9.1 just pulls that.  Does it not?

Comment 13

8 years ago
Hmmm... I've checked again and it seems that it was landed:

But I'm still having this issue on Thunderbird Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100302 Shredder/3.0.4pre
This landed after Gecko branched.  That's why the status1.9.1 flag above is set to ".9-fixed" (as in, fixed for

Comment 15

8 years ago
Ah... I understand. Thanks!
You need to log in before you can comment on or make changes to this bug.