SVG gradient/pattern paint is not applied to external file <use> content
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/aWYzLW?editors=1000 Steps to reproduce the problem: 1. Create an SVG sprite sheet (symbols or basic shapes to be re-used in other files). The elements should use inherited fill and stroke styles (i.e., not define their own fill or stroke). 2. Create SVG content (hosted on the same domain) that references elements in the sprite file via <use>. 3. Apply a pattern or gradient to the <use> in the fill or stroke property. The pattern or gradient should be defined in the same file as the <use> to avoid confounding effects from the fact that Chrome doesn't support cross-file paint references. What is the expected behavior? The shapes that are cloned by <use> should inherit the fill or stroke paint. They should be painted in the same way as shapes or symbols re-<used> from the same file. What went wrong? Chrome paints the shapes from the external file with the fallback color from the fill or stroke property, the way it would if there was an error such as being unable to find the referenced paint server. (If there is no fallback color, the shapes are not painted at all.) Does it occur on multiple sites: Yes Is it a problem with a plugin? N/A 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: The attached files are the same SVGs that are embedded in the linked CodePen. In order for the cross-file <use> references to work at all, they need to be hosted on the same domain. (localhost is fine, file: URL is not.) Works fine in Firefox, Safari, and MS Edge. I wouldn't be surprised if this bug was introduced at the same time as special handling of target-fragment only URLs. But I haven't done a dissect to confirm. I cannot be 100% certain that it worked previously; it's _possible_ I just never used paint servers on external <use> references. Not only does Chrome not use the gradient and pattern from the file with the `fill` declaration (which it should), but it also doesn't use paint-server elements with the same IDs in the external asset file (which it shouldn't, but it was worth confirming). So it's not a simple matter of the browser looking for the paint server target in the external file, or in the shadow tree.
,
May 12 2017
I can confirm that the bug is being issued in recent version of Chrome, because I did a computer general update 2 days ago on Windows 10 for security reason and before that my chrome was rendering the gradients no problems. Chrome: Version 58.0.3029.110 (64-bit) OS Version: Windows 10 Home, Version: 1607, OS Build: 14393.1198, 64-bit
,
May 12 2017
I suspect this may have been broken by the fix for url(...) references within shadow trees ( issue 597080 .) While waiting for this to be resolved "properly" (WIP), I'll try to come with a different cludge for picking a TreeScope in these cases...
,
May 12 2017
,
May 12 2017
Marking as a release blocker. Do you know when it was working?
,
May 12 2017
I've only tested in 58 (stable, where I discovered it) and 60 (Canary). Based on Comment #2, I suspect that the problem started in 58, but you'll want to double-check against 57.
,
May 12 2017
Based on my comment above, 58 would seem to be where it was introduced, so working in 57. Fix should be (is) simple and safe.
,
May 16 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6d8df7c57b4cc1beb9816b7379d88a48650dd507 commit 6d8df7c57b4cc1beb9816b7379d88a48650dd507 Author: fs <fs@opera.com> Date: Tue May 16 00:22:06 2017 Use CorrespondingUseElement() in SVGElement::TreeScopeForIdResolution For elements sourced non-locally, CorrespondingElement() will give the TreeScope of the document it was sourced from rather than the TreeScope of the <use> element. Until we are able to resolve references at ComputedStyle resolution, attempt to use the host of the shadow tree, i.e the (outermost) <use> element. (This will not work when external paint servers are supported, or with a paint server defined in the referenced document.) BUG= 721167 Review-Url: https://codereview.chromium.org/2877973002 Cr-Commit-Position: refs/heads/master@{#471955} [add] https://crrev.com/6d8df7c57b4cc1beb9816b7379d88a48650dd507/third_party/WebKit/LayoutTests/svg/custom/resources/rect100x100.svg [add] https://crrev.com/6d8df7c57b4cc1beb9816b7379d88a48650dd507/third_party/WebKit/LayoutTests/svg/custom/use-external-local-fill-expected.html [add] https://crrev.com/6d8df7c57b4cc1beb9816b7379d88a48650dd507/third_party/WebKit/LayoutTests/svg/custom/use-external-local-fill.html [modify] https://crrev.com/6d8df7c57b4cc1beb9816b7379d88a48650dd507/third_party/WebKit/Source/core/svg/SVGElement.cpp
,
May 16 2017
,
May 16 2017
Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 16 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1d80901cae8f06131cce44f0719d93cd580bd3df commit 1d80901cae8f06131cce44f0719d93cd580bd3df Author: Fredrik Söderquist <fs@opera.com> Date: Tue May 16 06:29:50 2017 Use CorrespondingUseElement() in SVGElement::TreeScopeForIdResolution For elements sourced non-locally, CorrespondingElement() will give the TreeScope of the document it was sourced from rather than the TreeScope of the <use> element. Until we are able to resolve references at ComputedStyle resolution, attempt to use the host of the shadow tree, i.e the (outermost) <use> element. (This will not work when external paint servers are supported, or with a paint server defined in the referenced document.) BUG= 721167 Review-Url: https://codereview.chromium.org/2877973002 Cr-Original-Commit-Position: refs/heads/master@{#471955} Review-Url: https://codereview.chromium.org/2887433003 . Cr-Commit-Position: refs/branch-heads/3071@{#576} Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641} [add] https://crrev.com/1d80901cae8f06131cce44f0719d93cd580bd3df/third_party/WebKit/LayoutTests/svg/custom/resources/rect100x100.svg [add] https://crrev.com/1d80901cae8f06131cce44f0719d93cd580bd3df/third_party/WebKit/LayoutTests/svg/custom/use-external-local-fill-expected.html [add] https://crrev.com/1d80901cae8f06131cce44f0719d93cd580bd3df/third_party/WebKit/LayoutTests/svg/custom/use-external-local-fill.html [modify] https://crrev.com/1d80901cae8f06131cce44f0719d93cd580bd3df/third_party/WebKit/Source/core/svg/SVGElement.cpp
,
May 16 2017
,
May 17 2017
Verified this issue on Mac OS 10.12, Ubuntu 14.04 and Windows-10 using chrome latest beta M59-59.0.3071.61 by following test case provided in the original comment, Observed the SVG gradient/pattern paint is applied to the external file <use> content as expected. Hence adding TE-Verified label.
,
May 23 2017
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by f...@opera.com
, May 11 2017Labels: -OS-Windows
Status: Available (was: Unconfirmed)