Closed Bug 462014 Opened 12 years ago Closed 9 years ago

cannot use svg filters in userContent.css

Categories

(Core :: SVG, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 308590

People

(Reporter: arno, Unassigned)

References

Details

Attachments

(2 files, 1 obsolete file)

Attached image svg filter
Hi,

My goal is to transform images in grayscale for people with vision problems. So, I'm trying to use svg filters [1] in an user agent stylesheet.

In userContent.css, I use following rule:

img {                                                                                                                               
    filter: url("bnw_filter.svg#filter");                                                                                                
} 

bnw_filter.svg is:
<svg xmlns="http://www.w3.org/2000/svg">
    <filter xmlns="http://www.w3.org/2000/svg" id="filter">
    <feColorMatrix xmlns="http://www.w3.org/2000/svg" type="saturate" values="0"/>
    </filter>
</svg>


Unfortunately, it does not work. Instead, I get following error:
> Security Error: Content at http://www.mozilla.org/projects/minefield/ may not
> load or link to
> file:///home/arno/.mozilla/firefox/vs5fvd6p.test/chrome/bnw_filter.svg.

putting svg filter in a chrome location, or loading a stylesheet with nsIStyleSheetService leads to the same problem.

[1]: https://developer.mozilla.org/web-tech/2008/09/15/svg-effects-for-html-content/
Attached file userContent.css (obsolete) —
Flags: wanted1.9.1?
Attachment #345126 - Attachment is obsolete: true
Ideally this would work (presumably by us using the principal of the nsCSSValue::URL for the same-origin check).

But then linking to a stylesheet on a different site (which is allowed) would also work, and that stylesheet could link to SVG on that different site...  That doesn't seem desirable.  Especially not if we then allowed the main page to <use> parts of that SVG (the mixed-origin case we think needs to be specced).

I suppose we could just move from hashing by URI to hashing by originating principal and URI, like the CSSLoader does, and then pass the originating principal through all this stuff...  roc, thoughts?
That sounds a little too complicated, especially since it will really only be useful for this case. (Right?)

Does a data: URL work here? Super ugly, but expedient.
A data: URL doesn't work because you can't specify a #foo reference for data:.

And yeah, doing the uri+principal hashtable would only be useful for ua/user styling of things given our current same-origin restrictions.
Flags: wanted1.9.1? → wanted1.9.1-
Blocks: 468835
Blocks: 507940
(In reply to comment #5)
> That sounds a little too complicated, especially since it will really only be
> useful for this case. (Right?)

Bug 507940 is another use case.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 308590
You need to log in before you can comment on or make changes to this bug.