Make external URL references work

• Component: SVG
• Status: NEW ---

[Rob Buis]

Follow-up for https://bugs.webkit.org/show_bug.cgi?id=63283

[Rob Buis]

Keeping this as a reminder for this bug:

> > Source/WebCore/css/SVGCSSStyleSelector.cpp:396
> > -            svgstyle->setMarkerEndResource(SVGURIReference::getTarget(s));
> > +            svgstyle->setMarkerEndResource(SVGURIReference::fragmentIdentifierFromIRIString(s, m_element->document()));
> 
> Oops, we silently assume same-document references here! If we just extract the fragment identifier here, we're going to ignore any external URL.
> We should store the whole IRI string here, and lookup the targetelmenetForIRIString later in rendering/ when we actually use the marker end resource.
> 
> That affects all usages of fragmentIdentifierFromIRIString - thery're all assuming same-doc refs, which is wrong.
> (Parts from our IRC discussion)

Cheers,

Rob.

Hi Rob,

  any progress on this issue ? Blocked #12499 is realy annoying for larger SVG applications.

Zbynek

[Renata Hodovan]

Is anybody working on this bug? I'm interested in this topic and I'd like to work on it if there are no objections.

[Alan Hogan]

Just want to follow this bug.

[Lea Verou]

Is there any progress on this? It’s practically crippling any non-trivial use case for SVG.

[Philip Rogers]

*** Bug 90955 has been marked as a duplicate of this bug. ***

[Philip Rogers]

I believe this bug refers to external SVG references with fragment URIs? External url references should work fine, with the caveat that fragment URIs do not work due to this longstanding issue: https://bugs.webkit.org/show_bug.cgi?id=6007

If this is indeed about the fragment URI bug, we should mark it as a duplicate of https://bugs.webkit.org/show_bug.cgi?id=91791.

@Lea, to my knowledge nobody is working on this at the moment :(

[Sérgio Gomes]

Hey folks!

Any news on this bug? Note that this is still present in current WebKit, in that if a document loads an external SVG file via SVG `<use>`, then any `url(#foo)` usage in that external SVG file fails, because it is apparently looking for `foo` in the importing document instead of the external SVG file.

To illustrate this, here is a small test page: https://sgomes.github.io/external-svg-with-filter/

It includes both a "correct usage" test, where both the filter and the element that makes use of it are defined inside the external SVG; as well as an "incorrect usage" test that matches WebKit's apparent expectation, where the filter is instead defined in the importing document.

Blink and Gecko pass the "correct usage" test by rendering the shadow, and pass the "incorrect usage" test by rendering an entirely white image.

Webkit fails the "correct usage" test by rendering an entirely white image, and fails the "incorrect usage example" by rendering the shadow.