Scrollbars are not being update using dss.enabled

RESOLVED FIXED

Status

()

Core
CSS Parsing and Computation
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: ShareBird, Assigned: bz)

Tracking

({fixed1.9.0.19, regression})

1.9.2 Branch
fixed1.9.0.19, regression
Points:
---

Firefox Tracking Flags

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

Details

Attachments

(2 attachments)

(Reporter)

Description

7 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: http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIChromeRegistry.idl#87

The extension is available at: https://addons.mozilla.org/en-US/firefox/addon/61769

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: http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?fromchange=7723073d61b2&tochange=ebba043bb505

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
Status: NEW → ASSIGNED
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?

r=dbaron
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+
Pushed:
  http://hg.mozilla.org/releases/mozilla-1.9.2/rev/e87a0bfee150
  http://hg.mozilla.org/releases/mozilla-1.9.1/rev/ed881b968aef

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
done
Checking in layout/style/nsLayoutStylesheetCache.h;
/cvsroot/mozilla/layout/style/nsLayoutStylesheetCache.h,v  <--  nsLayoutStylesheetCache.h
new revision: 1.9; previous revision: 1.8
done
Checking in layout/style/nsLayoutStylesheetCache.cpp;
/cvsroot/mozilla/layout/style/nsLayoutStylesheetCache.cpp,v  <--  nsLayoutStylesheetCache.cpp
new revision: 1.15; previous revision: 1.14
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
status1.9.1: --- → .9-fixed
status1.9.2: --- → .2-fixed
Keywords: fixed1.9.0.19
Resolution: --- → FIXED

Comment 8

7 years ago
>   http://hg.mozilla.org/releases/mozilla-1.9.2/rev/e87a0bfee150

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:
  http://hg.mozilla.org/releases/mozilla-1.9.2/rev/4bd1755a1619

Pushed to default branch:
  http://hg.mozilla.org/releases/mozilla-1.9.2/rev/7a9b9969e527
(Reporter)

Comment 11

7 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?
(Reporter)

Comment 13

7 years ago
Hmmm... I've checked again and it seems that it was landed:
http://mxr.mozilla.org/mozilla1.9.2/source/chrome/src/nsChromeRegistry.cpp#841
http://mxr.mozilla.org/comm-1.9.1/source/mozilla/chrome/src/nsChromeRegistry.cpp#899

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

Comment 15

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