462014 - cannot use svg filters in userContent.css

Status: RESOLVED DUPLICATE of bug 308590

(Core :: SVG, defect)

Description

[arno renevier]

Attachment: 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/

Comment 1

[arno renevier]

Attachment: userContent.css

Comment 2

[arno renevier]

Attachment: userContent.css with correct url

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

http://groups.google.fi/group/mozilla.dev.tech.svg/browse_thread/thread/7455235a07e42545

Comment 4

[Boris Zbarsky [:bzbarsky]]

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?

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

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.

Comment 7

[Markus Stange [:mstange]]

(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.