SVG external <use> references fail inside another <use> element's shadow DOM
Reported by
amelia.b...@gmail.com,
May 11 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36 Example URL: https://codepen.io/AmeliaBR/pen/KmopGy?editors=1000 Steps to reproduce the problem: 1. Create an SVG sprite file (content for re-use). 2. On another file hosted on the same domain, create <use> references to shapes or symbols from the first file. 3. In the second file, use additional <use> elements to re-use content that includes the external <use> references. What is the expected behavior? The nested use references should be followed (meaning, the content should be cloned), unless there are security restrictions preventing access to the external file at all. What went wrong? In Chrome, the external <use> references are not rendered when they are part of another <use> element's shadow tree. (Nested <use> references in the same file are rendered no problem. And direct references to the external file are rendered no problem, so long as both files are on the same domain.) Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 58.0.3029.96 Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 25.0 r0 Works in Firefox, Safari, and MS Edge. I haven't tested whether or not Chrome even tries to fetch the external file if the only references to it are indirect. (The test file uses both direct and indirect references.) The uploaded files match the ones used in the embed in the CodePen. The comments in the symbol file are related to a separate bug (#721167).
,
May 11 2017
,
May 12 2017
A comment/note on the testcase in passing after having looked at it... There's one (not unlikely) failure mode that I believe could go unnoticed, by the same 'id's (and with equivalent [visual] content) existing both in the local and external resources. (So resolving against the wrong document could, I believe, go unnoticed.)
,
May 12 2017
,
May 12 2017
What did this regress from? i.e. when was it working? Is M-59 stable too aggressive for a fix? That would require merges once fixed. An alternative is M-60 Beta blocker.
,
May 12 2017
I think this regression may be old (the assessment was based on the shape of the fix and the fact that it's reported to work in WebKit.) I would suspect c427062580ade2dde463ff0c51f33717099e6c9c, which is >1y old. If that is the case, then M-59 might be too aggressive. The fix is fairly simple (although not the oneliner I initially hoped.)
,
May 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a0de45f1fc217b5e308e5d58ef1ed43064f40ac4 commit a0de45f1fc217b5e308e5d58ef1ed43064f40ac4 Author: fs <fs@opera.com> Date: Sun May 14 16:39:15 2017 Nested <use>s can resolve against an external resource Rather than using TargetElementFromIRIString(...) when resolving nested <use> references, we should be using ResolveTargetElement(), since the latter also considers a possible external resource. BUG= 721196 Review-Url: https://codereview.chromium.org/2875303002 Cr-Commit-Position: refs/heads/master@{#471632} [modify] https://crrev.com/a0de45f1fc217b5e308e5d58ef1ed43064f40ac4/third_party/WebKit/LayoutTests/svg/custom/resources/green-rect.svg [add] https://crrev.com/a0de45f1fc217b5e308e5d58ef1ed43064f40ac4/third_party/WebKit/LayoutTests/svg/custom/use-nested-external-href-expected.html [add] https://crrev.com/a0de45f1fc217b5e308e5d58ef1ed43064f40ac4/third_party/WebKit/LayoutTests/svg/custom/use-nested-external-href.html [modify] https://crrev.com/a0de45f1fc217b5e308e5d58ef1ed43064f40ac4/third_party/WebKit/Source/core/svg/SVGUseElement.cpp [modify] https://crrev.com/a0de45f1fc217b5e308e5d58ef1ed43064f40ac4/third_party/WebKit/Source/core/svg/SVGUseElement.h
,
May 15 2017
(Dropping pri again because of the guestimated age.)
,
May 15 2017
[Auto-generated comment by a script] We noticed that this issue is targeted for M-59; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-59 label, otherwise remove Merge-TBD label. Thanks.
,
May 16 2017
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by amelia.b...@gmail.com
, May 11 2017