Open Bug 428892 Opened 16 years ago Updated 2 years ago

userchrome.css stylesheet blocked from referencing theme images

Categories

(Core :: General, defect, P5)

Product:
Core
Component:
General
Type:
defect

Tracking

()

People

(Reporter: ts.bugzilla, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression) 

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

The style rule
"richlistitem[type="download"][selected=true] {
  background-image: url(chrome://mozapps/skin/shared/itemSelected.png) !important;}"
when put in userchrome.css causes the error
"Security Error: Content at file:///<...>/Profiles/MozFire_3/chrome/userChrome.css may not load or link to chrome://mozapps/skin/shared/itemSelected.png."
My impression is that this makes userchrome.css pretty pointless.
Possibly caused by bug 292789.

Reproducible: Always
Blocks: 292789
_definitely_ caused by bug 292789.

You could replace the chrome: reference with a resource: one, but then that's only going to be able to reference the default theme:
   url(jar:resource://gre/chrome/classic.jar!/<path>/itemSelected.png)

or pull out the images you're using into a fixed location and reference them there, which is kind of the point. The built-in stuff is internal details, we don't really want people relying on it. They aren't a promise and we will move things around.

Or, if you're the sort that messes with userChrome.css, you could also add "contentaccessible=yes" to the appropriate .manifest file in your install directory.
(In reply to comment #1)
> _definitely_ caused by bug 292789.

Thanks for the confirmation...

> or pull out the images you're using into a fixed location and reference them
> there, which is kind of the point. The built-in stuff is internal details, we
> don't really want people relying on it. They aren't a promise and we will move
> things around.

The steps I took was to "download" the chrome: resource URI, and use a local PNG file in a file: uri (ugly long paths included).

> Or, if you're the sort that messes with userChrome.css, you could also add
> "contentaccessible=yes" to the appropriate .manifest file in your install
> directory.

That doesn't sound like it's gonna work with automatic nightly updates... I suppose it breaks the checks for applicability of the patches.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I have begun to see this message on trunk builds for a .css which my extension's JS tries to load for messages (i.e. not JS code within messages). Would you say this is the relevant bug?
Nice.  XBL bindings through userChrome.css are busted too.  (Though we shouldn't be doing XBL bindings to extensions there anyway...)
This clearly worked in Firefox 2.
Keywords: regression
Flags: wanted1.9.0.x?
(In reply to comment #5)
> Nice.  XBL bindings through userChrome.css are busted too.

Is that an answer to my question?
Does this also explain bug 440215 ?
Yes, this does explain bug 440215.  flashblock's inability to show the icons
it normally shows are due to this.
Carrying blocking request over from bug 439330.
Flags: blocking1.9.0.1?
Has anything changed here since the assertion in comment 1 which basically asserts that this is WFM/INVALID as per bug 292789 ?
Flags: blocking1.9.0.1? → blocking1.9.0.1-
Comment 1 says that to let userChrome.css access chrome, you must let all
web content access chrome.  That's the issue.  The whole point of userChrome
is to change the behavior of chrome, and ought not require a weakening of 
other security to accomplish it.
Flags: blocking1.9.1?
I can understand not letting userContent.css access chrome, but I don't see the point of blocking userChrome.css.
Dan, thoughts here?
Doesn't meet the "wanted" criteria (security, stability, regression from maintenance release) for 1.9.0.x. However, we'll look at a reviewed and baked patch.
Flags: wanted1.9.0.x? → wanted1.9.0.x-
It doesn't meet the regression criteria?  How could it not? 
This is a feature that has worked for years, and now does not.
(In reply to comment #16)
> It doesn't meet the regression criteria?  How could it not? 

The criterion is "regression *from a maintenance release*", not just "regression". This bug was introduced in Firefox 3.
Note also that "wanted1.9.0.x-" does not imply that a patch will not be accepted for 1.9.0.x.
(In reply to comment #17)
> The criterion is "regression *from a maintenance release*", not just
> "regression". This bug was introduced in Firefox 3.

What do you mean? This is a regression from a maintenance release. Are you saying it is not?
(In reply to comment #19)
> What do you mean? This is a regression from a maintenance release. Are you
> saying it is not?

Bug 292789 landed before Firefox 3, and this bug is caused by bug 292789. Is that incorrect?
No, that is correct, so that means this is a regression from a maintenance release, no?
Firefox 3 is a major release, not a maintenance release.
Ah, ok, sorry, I thought it was a maintenance release.
(In reply to comment #22)
> Firefox 3 is a major release, not a maintenance release.

Oh, so you mean that a bug which was caused by something earlier than the latest major release can never be nominated "wanted" for anything, even if creating that bug was never intentional?
It can be nominated but it will not be plussed, with few exceptions. That being said, we'll definitely look at all patches which request approval and make decisions on a patch-by-patch basis, this bug included.
(In reply to comment #11)
> Has anything changed here since the assertion in comment 1 which basically
> asserts that this is WFM/INVALID as per bug 292789 ?

the fix in bug 292789 intentionally broke chrome: references from web content. Given what it's designed for, userChrome.css should logically be treated as chrome making this a valid bug.

The work-arounds in comment 1 were just that: work-arounds, not claims that this is an invalid bug.
Not blocking 1.9.1, but I think we need to come to some conclusion on how we're going to fix this.  So, marking this as wanted1.9.1+ with a P1 priority.  What this means is that if it doesn't get fixed by 1.9.1 (which it likely won't), we'll put this on the list for the list right after 1.9.1.
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Priority: -- → P1
This bug getting fixed for what is considered a very bad practice isn't worth IMHO. userChrome.css writers and extensions developers should never point to an image that is "supposed" to be in the place they want. Remember that there are a couple themes which aren't clones from default theme, it should be possible for theme developers to position their icons and named them like they want. Just my two cents...
Blocks: 388642
Decreasing the priority as no update for the last 2 years on this bug.
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage 
about the priority meaning.
Priority: P1 → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.