Closed Bug 424184 Opened 16 years ago Closed 15 years ago

Can no longer style scrollbars from userchrome.css or usercontent.css

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: alta88, Unassigned)

Details

(Keywords: regression) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031004 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031004 Minefield/3.0b5pre


the following css no longer works in recent trunk builds, regression from Fx2.

scrollbarbutton { 
  -moz-appearance: none !important; 
  display: none !important; 
}

Reproducible: Always
Keywords: regression
Component: General → Style System (CSS)
Product: Firefox → Core
QA Contact: general → style-system
Version: unspecified → Trunk
Blocks: 424535
Non-UA stylesheets cannot style native anonymous content anymore.  See bug 285140 for the reasons.

I think this should be wontfix, but it's up to dbaron as module owner.
i don't really see any reasons in that bug.

according to the author, Stylish is UA.  doesn't work.  are you also saying Fx doesn't apply rules in userchrome/usercontent.css as UA?  that seems way wrong.

big picture: it would be extremely egregious to prevent a user from styling this aspect of chrome/content.  web sites are one thing, agreed.  but client side?  i don't care about native OS for this, and if i want to override there is no reason i can think of that should prevent it.

> i don't really see any reasons in that bug.

Um... I can only suggest reading more carefully.

> according to the author, Stylish is UA. 

That should work, then.

> are you also saying Fx doesn't apply rules in userchrome/usercontent.css
> as UA?

That's correct.  They're applied as user stylesheets.

> that seems way wrong.

I don't see how we could be any clearer that they are _user_ style sheets....  Are the names not clear enough?

> it would be extremely egregious to prevent a user from styling
> this aspect of chrome/content.

Any user who really really wants to (and I don't expect there are many) can easily write an extension that will add a UA stylesheet that will do this.  Or just a generic extension that allows loading stylesheets as UA sheets (if one doesn't exist already, which I doubt).  But then they need to realize that they can easily create rules that could seriously screw up their browser, which is something that we decided user stylesheets shouldn't be able to do because people were shooting themselves in the foot pretty often.

 
(In reply to comment #3)
> > i don't really see any reasons in that bug.
> 
> Um... I can only suggest reading more carefully.

you'll have to really explain it then.  apparently, someone technical enough went into their usercontent.css, put in a rule to not display <br>, and was confused why <br> was not displaying.  so you shut down usercontent.css?
> 
> > according to the author, Stylish is UA. 
> 
> That should work, then.

it doesn't.  i think jason knows what he's doing.
> 
> > it would be extremely egregious to prevent a user from styling
> > this aspect of chrome/content.
> 
> Any user who really really wants to (and I don't expect there are many) can
> easily write an extension that will add a UA stylesheet that will do this.  Or
> just a generic extension that allows loading stylesheets as UA sheets (if one
> doesn't exist already, which I doubt).  But then they need to realize that they
> can easily create rules that could seriously screw up their browser, which is
> something that we decided user stylesheets shouldn't be able to do because
> people were shooting themselves in the foot pretty often.
> 

this logic is just baffling.  are you really not aware of how many people use usercontent/userchrome?  and even without shooting themselves in the foot.

are you actually saying people will have to, quote "easily", write extensions to style their browser where before all they had to do was add a few lines in a local file?  and that they can now hide their statusbar but can't hide a scrollbar because that's treated differently?

this is all very wrong. i really would like to hear a cogent explanation, with something besides "it helps babies" reasoning..


Perhaps bug 286895 explains the problem more clearly.  Someone went into userContent.css and added a rule and it affected something that they were totally not expecting it to affect: native anonymous content.

> are you really not aware of how many people use usercontent/userchrome? 

I'm well aware.  I doubt many want it to style native anonymous content.  We've had no reports of this being an issue in the almost a year since that change.  Before that we had a number of bugs filed on the problem bug 286895 fixed.

Nothing about helping babies, everything about helping users.
And the point is, it's trivial to add user stylesheets via various extensions, so  people are putting all sorts of rules in there....  These are not "technical enough" people.

> it doesn't.  i think jason knows what he's doing.

I would love to see a bug to this effect, with the exact CSS and the exact way it's being loaded.  I just tested this here, and it works.
first, let's be clear that a user's ability to style each and every chrome/content element in their browser is _far_ more important than preventing their errors when doing so.  like, we (maybe) wouldn't ban books and paper if a baby got a paper cut once.

second, if an element is of a type anonymous, and the goal is to not allow styling anon type when also styling non-anon, then you've gone about fixing this totally incorrectly via blanket removal.  a correct design would have it explicitly required to state 'anon', ie an overt, non unintended action.  like div[anon] or such.

third, why are scrollbar elements anon?  esp chrome?  it's actually funny that you claim people don't want to style anon, but then change scrollbar to anon.  thus making people want to style anon.

last, you don't "help users" by helping some and hurting others.  expecting people to add "trivial" stylesheets is a nonstarter if you consider it an equivalent replacement to a local file.

i will contact stylish and point him here, as it is clearly a bug somewhere if stylish doesn't work.  perhaps you could do a fast test..

thanks for your attention.
The ability to style everything hasn't been removed.  It just requires a bit more understanding, which I think is appropriate given some of the dangers involved.

Your proposed syntax for styling anonymous content would conflict with existing CSS syntax.  You're right that it would be a good idea to allow this, but the syntax issue is important.  Also important is that the anonymous content is subject to change with no notice in any release (including security point releases).

> third, why are scrollbar elements anon? 

The scrollbar is not.  The parts _inside_ the scrollbar are.  For what it's worth, I believe roc plans to remove those parts completely (so the only XUL element involved will be the <scrollbar> and the rest will be handled completely at paint-time).

> last, you don't "help users" by helping some and hurting others.

You do if there are a lot more of the former, sorry.  Life is full of tradeoffs.
(In reply to comment #8)
> The ability to style everything hasn't been removed.  It just requires a bit
> more understanding, which I think is appropriate given some of the dangers
> involved.
> 

it's not even documented, is it?  

> Your proposed syntax for styling anonymous content would conflict with existing
> CSS syntax.  You're right that it would be a good idea to allow this, but the
> syntax issue is important.

nonsense, how?  div:anon, div[:anon], div {-moz-anon: yes} etc.

>  Also important is that the anonymous content is
> subject to change with no notice in any release (including security point
> releases).
> 

so?  irrelevant.  updating css syntax is nothing.  yanking previously working functionality is relevant.

> > third, why are scrollbar elements anon? 
> 
> The scrollbar is not.  The parts _inside_ the scrollbar are.  For what it's
> worth, I believe roc plans to remove those parts completely (so the only XUL
> element involved will be the <scrollbar> and the rest will be handled
> completely at paint-time).
> 

please explain what this would mean.  right now, i don't see <scrollbar> in DOMi in minefield (other than History/Bookmarks in sidebar), just <xul:scrollbox>.

> > last, you don't "help users" by helping some and hurting others.
> 
> You do if there are a lot more of the former, sorry.  Life is full of
> tradeoffs.
> 

please avoid the platitudes.  and i absolutely disagree this tradeoff is even necessary, it seems to be just a matter of not wanting to bother fixing a poorly conceived/implemented checkin.  sorry.
Alta88, I added a script here that I think does what you want:
http://martijn.martijn.googlepages.com/scrpttest.htm
It uses enhanced privileges, so you need to download it to your computer.
Removing the user's ability to change their scrollbars via userChrome.css or usercontent.css is a really bad regression. This bug should be fixed before Firefox 3.0 is released, because otherwise there is going to be a lot of disappointed users who do go all out to customize the look of their browser. Maybe this will be a small minority of users overall, but still the numbers would be significant and they will probably be the most vocal.

In my case, this bug has thrown a monkey wrench into the plans I had for the theme Classic Compact, which I maintain (see: http://forums.mozillazine.org/viewtopic.php?t=640240). Because of bug 423780 (which effects WinXP) I was forced into using custom scrollbars so that I could distribute a single JAR file for all OSes. Now understandably, some users wanted to maintain their OS native scrollbars. My intention had been to provide users of my theme with an option to change their scrollbar styling.  This was going to be done via an options panel I am developing as a companion extension for my theme, which will also allow users to change other aspects of the theme.

Unfortunately, because of this bug I can not give users any choice in scrollbar styling, even though I can give them the ability to change many other design elements of my theme.

This bug is denying me a nice work around to bug 423780 and is limiting the options I can provide users of my theme.  This bug and bug 423780 are big deals because they force me to choose between unacceptable solutions to work around the problems they both cause.

Now I have to find a work around to this bug so that I can use a work around to another bug. Work arounds to work arounds only create unnecessary complexity.
Adding to my comment above.

To see the code I'm using that this bug breaks please see: http://forums.mozillazine.org/viewtopic.php?t=645835

There are three different user options that were supposed to change the styling of scrollbars in different ways (among doing other things).
> Unfortunately, because of this bug I can not give users any choice in scrollbar
> styling

Why not?  Just put the user choices into a UA stylesheet.  Your extension probably shouldn't be writing to userChrome.css/userContent.css to start with...
The following code is why not.  It is called by the optional extension for my theme and ONLY the stylesheet code is not working.  Maybe there is a different way to do this, but the documentation about this stuff is so bad that I have not found it. The idea is simple the theme styles everything one way and then if the user has changed their preferences via the optional extension the extension calls stylesheets that override the theme.

---Begin Code---
var ccpreferences = {
	pref: Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefService).getBranch("extensions.classiccompactoptions."),
	firefox: null,
	mainWindow: null,
	init:function() {

		this.sss = Components.classes["@mozilla.org/content/style-sheet-service;1"].getService(Components.interfaces.nsIStyleSheetService);
		this.ios = Components.classes["@mozilla.org/network/io-service;1"].getService(Components.interfaces.nsIIOService);
		var buttonsclassic2uri = this.ios.newURI("chrome://global/skin/themeoptions/buttonsclassic2.css", null, null);
		var keyholeuri = this.ios.newURI("chrome://global/skin/themeoptions/keyholearrows.css", null, null);
		var flatbackgroundsuri = this.ios.newURI("chrome://global/skin/themeoptions/flatbackgrounds.css", null, null);
		var chiseleddividersuri = this.ios.newURI("chrome://global/skin/themeoptions/chiseledborders.css", null, null);
		var squarecornersuri = this.ios.newURI("chrome://global/skin/themeoptions/squarecorners.css", null, null);
		var nativescrollbarsuri = this.ios.newURI("chrome://global/skin/themeoptions/nativescrollbars.css", null, null);


		if(this.pref.getCharPref("toToolbarButtons")=="cc2"){
			this.sss.loadAndRegisterSheet(buttonsclassic2uri, this.sss.USER_SHEET);
		}
		if(this.pref.getCharPref("toArrows")=="keyhole"){
			this.sss.loadAndRegisterSheet(keyholeuri, this.sss.USER_SHEET);
		}
		if(this.pref.getCharPref("toBackgrounds")=="flat"){
			this.sss.loadAndRegisterSheet(flatbackgroundsuri, this.sss.USER_SHEET);
		}
		if(this.pref.getCharPref("toToolbarDividers")=="chiseled"){
			this.sss.loadAndRegisterSheet(chiseleddividersuri, this.sss.USER_SHEET);
		}
		if(this.pref.getCharPref("toCornerStyles")=="square"){
			this.sss.loadAndRegisterSheet(squarecornersuri, this.sss.USER_SHEET);
		}
		if(this.pref.getCharPref("toScrollbars")=="os"){
			this.sss.loadAndRegisterSheet(nativescrollbarsuri, this.sss.USER_SHEET);
		}
	}
};
---End code---

To try this out install the following test copies of my theme and extension:
    * Theme: http://environmentalchemistry.com/classiccompact.jar (480kb)
    * Extension: http://environmentalchemistry.com/classiccompactoptions.xpi (6kb)
Edit to above comment, it should have read:

"It is called by the optional extension for my
theme and ONLY the scrollbar stylesheet code is not working."
The example I posted in comment 10 works, no?
I just made it from the examples that are posted in: http://developer.mozilla.org/en/docs/Using_the_Stylesheet_Service
No it did not work.  If you look at my code and your code you will see the only significant difference is:

--code--
netscape.security.PrivilegeManager.enablePrivilege('UniversalPreferencesRead UniversalPreferencesWrite UniversalXPConnect');
--code--

I added this to my script and nothing happened for scrollbars.  I even tried placing this code inside and then outside of the function calling the custom stylesheets

Even without the above code, the style sheets are being called and their instructions are being applied throughout the theme with the lone exception being scrollbars. 

It appears that the only place that scrollbars can be customized is within a theme JAR file via the standard scrollbars.css file. Whatever change was made to stop websites from mucking with scrollbars, it also broke the ability for loadAndRegisterSheet() and usercontent.css to be able to have any effect on scrollbars.  This is a totally undesirable behavior.  
Well, it works here using current trunk build.
I am using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040606 Minefield/3.0pre

This is the latest build available via automatic updates. I am not able to touch scrollbar styling from my extension using the loadAndRegisterSheet() function with or without the following privilege manager code EVEN though the very same style calls have an effect everywhere else within the theme.

--code--
netscape.security.PrivilegeManager.enablePrivilege('UniversalPreferencesRead
UniversalPreferencesWrite UniversalXPConnect');
--code--

I have placed the above instruction in three different places within my overlay.js file and it did not change any styling behavior.  Again even without this line of code, my extension works exactly as it should on all style elements that each option is supposed to change except within scrollbars.

I do not know why it works in your demo, but it does not work in my actual code and I can not find any material difference between your demo and the section of my overlay.js file that calls alternative stylesheets.

I placed a copy of my overlay.js code in comment #14 above and a working demonstration can be tried by installing the following two files:
  * Theme: http://environmentalchemistry.com/classiccompact.jar (480kb)
  * Extension: http://environmentalchemistry.com/classiccompactoptions.xpi
(6kb)

You are welcome to crack open the extension and see the actual code yourself. This might help narrow down why your hack works for your code, but not for mine.

With that said, even if it did work, elevating privileges via a hack like this just sounds like a dangerous workaround to the problems caused by this bug. I mean, what bad side effects could this elevation have?


You are using USER_SHEET, I think you should be using AGENT_SHEET to be able to style the scrollbars in content.

You don't need to elevate privileges, extensions already have elevated privileges. But maybe I'm misunderstanding you here?
THANK YOU!!

AGENT_SHEET did the trick and without the elevated privileges.

Now I just wish Mozilla would hire a brigade of technical writers to get the documentation up to a level where one could find all these little details and quirks without beating one's head against the keyboard for days and depending upon the mercy of someone else to find these little tricks.

I'm telling you, the worst documented stuff in the world is anything dealing with any kind of programing. 

I do think users should be able to use usercontent.css or userchrome.css to change their scrollbars around, however, the AGENT_SHEET does address extension developers.
Ok, I'm glad that you got it working.

(In reply to comment #21)
> I do think users should be able to use usercontent.css or userchrome.css to
> change their scrollbars around, however, the AGENT_SHEET does address extension
> developers.

Yeah, I'm  a bit surprised too that users can't change their content scrollbars anymore with userContent.css or userChrome.css.
But I guess that content scrollbars are part of native anonymous content.
I guess it would be nice to have a userUA.css, just like we have userContent.css and userChrome.css?

http://developer.mozilla.org/en/docs/Using_the_Stylesheet_Service documents USER_SHEET vs AGENT_SHEET.  You're right that there is no documentation on the unsafe things that agent sheets can do that no one else can do.  Of course the documentation _is_ a wiki...
Maybe not strictly related to this bug, my extension RichScrollbar doesn't work on FF3. I must leave its development. It is based on a XBL component binding standard browser window scrollbars.
The XBL component under FF3 can't no more call getAttribute/setAttribute

OK, I'm going to wontfix this.  I really don't think we want to change this behavior back to the way it was before.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
No longer blocks: 424535
You need to log in before you can comment on or make changes to this bug.