Bug 100269

<rdar://problem/12565751>

Tim says http://trac.webkit.org/changeset/99539 is related.

Dirk, ping?

Actually <rdar://problem/12563956>.

I won't have time to investigate in this for the next weeks :(

All of the failing examples, and there are many of them, are in cases where the effect is defined via CSS. So in reality this is a case of no CSS applied when the svg content is embedded as-image.

(In reply to comment #6) > All of the failing examples, and there are many of them, are in cases where the effect is defined via CSS. So in reality this is a case of no CSS applied when the svg content is embedded as-image. I don't think so, because many of the examples work when reloading. I think it's some caching thing.

(In reply to comment #7) > (In reply to comment #6) > > All of the failing examples, and there are many of them, are in cases where the effect is defined via CSS. So in reality this is a case of no CSS applied when the svg content is embedded as-image. > > I don't think so, because many of the examples work when reloading. I think it's some caching thing. IIRC, in all failing cases, the referenced SVG has resources like images and fonts, right?

Actually I don't get this at all. The source for the drop shadow example is http://www.voormedia.nl/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/dropshadow-de0ba3e8.svg This just has an <image> with a data URI. I don't see any filters there at all. So maybe we're just not loading data URIs? But this also makes it not a test of SVG features, suggesting that the page is just bogus. I do notice: <!-- Generator: Adobe Illustrator 16.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->

(In reply to comment #9) > Actually I don't get this at all. > The source for the drop shadow example is > http://www.voormedia.nl/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/dropshadow-de0ba3e8.svg > > This just has an <image> with a data URI. I don't see any filters there at all. So maybe we're just not loading data URIs? > > But this also makes it not a test of SVG features, suggesting that the page is just bogus. I do notice: > > <!-- Generator: Adobe Illustrator 16.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) --> Hey, "Adobe Illustrator 16.0.0, SVG Export Plug-In" is no sign for a bogus page ;). No, we discussed this before, many "filters" are no filters on this page. But not all failing tests have images, some load fonts, which does not seem to work either. If at all, it is a general loading issue.

(In reply to comment #10) > (In reply to comment #9) > > Actually I don't get this at all. > > The source for the drop shadow example is > > http://www.voormedia.nl/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/dropshadow-de0ba3e8.svg > > > > This just has an <image> with a data URI. I don't see any filters there at all. So maybe we're just not loading data URIs? > > > > But this also makes it not a test of SVG features, suggesting that the page is just bogus. I do notice: > > > > <!-- Generator: Adobe Illustrator 16.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) --> > > Hey, "Adobe Illustrator 16.0.0, SVG Export Plug-In" is no sign for a bogus page ;). No, we discussed this before, many "filters" are no filters on this page. But not all failing tests have images, some load fonts, which does not seem to work either. If at all, it is a general loading issue. Do we not allow SVG in <img> to load subresources?

(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > Actually I don't get this at all. > > > The source for the drop shadow example is > > > http://www.voormedia.nl/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/dropshadow-de0ba3e8.svg > > > > > > This just has an <image> with a data URI. I don't see any filters there at all. So maybe we're just not loading data URIs? > > > > > > But this also makes it not a test of SVG features, suggesting that the page is just bogus. I do notice: > > > > > > <!-- Generator: Adobe Illustrator 16.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) --> > > > > Hey, "Adobe Illustrator 16.0.0, SVG Export Plug-In" is no sign for a bogus page ;). No, we discussed this before, many "filters" are no filters on this page. But not all failing tests have images, some load fonts, which does not seem to work either. If at all, it is a general loading issue. > > Do we not allow SVG in <img> to load subresources? We do. It was limited up to a certain grade of references (load svg, that loads an svg that loads an image...). But this is a single reference and should work. And id does after relaoding the page. Guess out of the blue: Maybe we don't repaint if the resource is available at a later point? This could make sense on SVGImage

It's not a repaint bug. Resizing the window doesn't fix it.

(In reply to comment #9) > Actually I don't get this at all. > The source for the drop shadow example is > http://www.voormedia.nl/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/dropshadow-de0ba3e8.svg > > This just has an <image> with a data URI. I don't see any filters there at all. So maybe we're just not loading data URIs? > > But this also makes it not a test of SVG features, suggesting that the page is just bogus. I do notice: > > <!-- Generator: Adobe Illustrator 16.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 0) --> The drop shadow is not a filter or a shadow declaration. Rather, the shadow is a path drawn with black fill, with the fill defined in the <style> block. All the examples use CSS in this way. The font test does not actually load a custom font, it just defines a font face in the style block. This produces the shadow, or should: <style type="text/css"> <![CDATA[ .st0{fill:#DDDDDD;} ]]> </style> <path class="st0" d="M42.5,38.12c0,2.42-1.96,4.38-4.38,4.38H11.88c-2.42,0-4.38-1.96-4.38-4.38V11.88c0-2.42,1.96-4.38,4.38-4.38 h26.25c2.42,0,4.38,1.96,4.38,4.38L42.5,38.12L42.5,38.12z"/> Hence, the issue is CSS on the first load/paint of an SVG as-image. I'm willing to bet that Illustrator's SVG export was explicitly designed to avoid using poorly implemented features (particularly IE previous to IE10). Instead, it uses basic geometry to fake the filter effects.

Created attachment 243595 [details] drop-shadow.svg

Updating this bug with findings thus far. The URLs to the tests that fail: http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/customfont-0cbd7700.svg http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/dropshadow-de0ba3e8.svg http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/gaussianblur-5db6ec7e.svg http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/outerglow-b3d2cb3f.svg http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/innerglow-c57e5b8f.svg http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/imageembed-213ab9f2.svg http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/imagelink-18d12bc3.svg http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/gradientmesh-19c02adf.svg All these documents render fine stand-alone; they do not completely render when embedded in an HTML document using an <img> tag. Specifically, the <image> elements in these SVG docs do not render. Note that in all these documents - except one; more below - the <image> is a data URI and thus passes the sub-resource security check in CacheResourceLoader::canRequest(). I have attached one example: - drop-shadow.svg - img-drop-shadow.html Make sure to load these files in different tabs. If you load the SVG file first, then the HTML doc will subsequently render fine. In the debugger, the one visible difference I noticed between one vs. the other: When loading drop-shadow.svg, ImageLoader::renderImageResource() eventually runs through the is<RenderSVGImage> branch: if (is<RenderSVGImage>(*renderer)) return &downcast<RenderSVGImage>(*renderer).imageResource(); This does not occur when the same document is loaded by an HTML <img>. It suggests the resource loader may not complete successfully but I am as of yet unable to figure out why. Note that the first document above - http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/customfont-0cbd7700.svg - fails even though it does not involve a sub-resource. I have not looked into this case yet.

Created attachment 243597 [details] img-drop-shadow.html

> The drop shadow is not a filter or a shadow declaration. Rather, the shadow is a path drawn with black fill, with the fill defined in the <style> block Actually, no. The path is a rounded rect. The "drop shadow" is actually a PNG file in a data URI.

I think this is just about SVG in image not loading resources, including data URIs.

http://www.voormedia.nl/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/svg-browser-test isn't testing any SVG features at all. All the "your browser" images just reference effects burnt into a PNG referenced via a data URI. And we don't load those data URIs because SVGImage isn't set up to load any resources. In order to do so, it needs a FrameLoaderClient which implements a few things including createNetworkingContext(), and that FrameNetworkingContext has to implement scheduledRunLoopPairs() by getting it from the Page, and the page has to have had addSchedulePair() called on it with some platform-specific runloop data. Also, image loading needs to be enabled in the Page's Settings: m_page->settings().setLoadsImagesAutomatically(true); However, we can't fix any of this until we decide on a policy of which kinds of resources SVGImages are allowed to load.

Simon, thanks for filling in the picture. Though I do not mind going through all these interesting motions it does sound like larger decisions need to be made. How do you want to proceed? I think it is important to bear in mind that this works in other browsers. So unless there is a compelling argument to *not* do this I assume we are really trying to scope the work. Is that fair? Last, one of the tests still puzzles me: http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/customfont-0cbd7700.svg As far as I can tell there is no @font-face for the font-family in this document, either in the HTML page that embeds it or the SVG document. Yet it fails. Is that a variant of the problem you describe or something worth investigating separately?

Here's what Sam thinks we should do (and I agree with him). We should figure out what the cross-compat story is here by filling in a matrix of whether the load is allowed with combinations of same/different origins for the host page, SVGImage, and the external resource. We should probably always allow data URI loading too.

That seems the right approach for SVG compat overall but when it comes to *this* specific test page, I want to be very clear: none of the tests involve an actual resource download. No origins, cross-origins or HTTP requests were harmed in the making of this movie. Everything here involves either data URIs or nothing at all: the 'custom font' case simply uses an unknown font-family name and that is enough for text to disappear when the SVG is referenced by an <img>. Note that all these effects are rendered using data URIs because the SVG files were exported by Illustrator; legacy code on our end simply rasterizes a number of effects this way. Though we are keen on fixing that we still expect this failure to occur with existing content and generally trip up web developers. It's one thing to fail cross-origin in one browser but not the other. It's another to fail when page *and* SVG are in the same domain *and* the latter use 100% local data-URIzed content. And text disappearing if the font name can't be matched. Thus fixing this particular test page only requires addressing the column or row of Sam's matrix that concerns data URIs inside an embedded SVG; which we know to pass in IE10+, Firefox and Chrome. (And I do not expect that to change). Is this a subset of the problem that could be independently tackled? Or maybe addressed as a first stage? Your earlier comment about what SVGImage needs suggests the effort required may not be so different from biting on the full thing...

(In reply to comment #23) > Thus fixing this particular test page only requires addressing the column or > row of Sam's matrix that concerns data URIs inside an embedded SVG; which we > know to pass in IE10+, Firefox and Chrome. (And I do not expect that to > change). Is this a subset of the problem that could be independently > tackled? Or maybe addressed as a first stage? Your earlier comment about > what SVGImage needs suggests the effort required may not be so different > from biting on the full thing... Yes, fixing data URIs can be tackled independently. However, that may involve hacking loading code to not send data URIs through the networking layer, which we do now (stupidly).

Looks like Said is fixing data URIs via bug 99677.

Looks like Said's fix in 99677 has fixed all the tests on the page except two: http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/imagelink-18d12bc3.svg This test loads a sub-resource, which SVG as <img> forbids. So this is as expected. http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/customfont-0cbd7700.svg This one remains a bug. Though the test is called 'customfont', all that is involved is an unknown font family name. This should not fail. I will look into the latter.

All the SVG images in http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/svg-browser-test are now fixed. The last problem was fixed in https://bugs.webkit.org/show_bug.cgi?id=68090. So closing this bug as a duplicate. NOTE: The image labelled 'img-link' in the voormedia test page should not be displayed because of security reasons. The test page claims wrongly that the image should be displayed while it should not. All other browsers agree on not showing this particular image. *** This bug has been marked as a duplicate of bug 68090 ***

As noted in comment #26, there remains an issue with http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/customfont-0cbd7700.svg. In this case, no text is visible when the SVG resource is embedded and the font family name is unknown. This should not fail. I haven't yet been able to track down the cause and haven't had much time to investigate.

(In reply to comment #29) > As noted in comment #26, there remains an issue with > http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum- > browser-compatibility/images/customfont-0cbd7700.svg. In this case, no text > is visible when the SVG resource is embedded and the font family name is > unknown. This should not fail. > > I haven't yet been able to track down the cause and haven't had much time to > investigate. As I mentioned above, the custom font issue in the voormedia test page turned out to be due having the WebCore DefaultFontSetting is set to zero. Changing this setting to be 16 instead of 0 fixes the issue. Please sync the revision r184719 and you will see that the issue is fixed.

(In reply to comment #30) > (In reply to comment #29) > > As noted in comment #26, there remains an issue with > > http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum- > > browser-compatibility/images/customfont-0cbd7700.svg. In this case, no text > > is visible when the SVG resource is embedded and the font family name is > > unknown. This should not fail. > > > > I haven't yet been able to track down the cause and haven't had much time to > > investigate. > > As I mentioned above, the custom font issue in the voormedia test page > turned out to be due having the WebCore DefaultFontSetting is set to zero. > Changing this setting to be 16 instead of 0 fixes the issue. Please sync the > revision r184719 and you will see that the issue is fixed. By the way opening the link http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/images/customfont-0cbd7700.svg shows the text as expected without the fix of https://bugs.webkit.org/show_bug.cgi?id=68090. But the bug can be seen when loading the SVG as a resource referenced by an HTML or an another interactive SVG. For example http://voormedia.com/blog/2012/10/creating-svg-vector-graphics-for-maximum-browser-compatibility/svg-browser-test shows the bug clearly and which should be fixed now in WebKit.

*** This bug has been marked as a duplicate of bug 68090 ***