Inline SVG fragment identifiers may miss locally scoped fragments
Reported by
m...@meshul.am,
Jan 11 2017
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 Steps to reproduce the problem: 1. Create two SVGs in an HTML document 2. In each SVG, create a gradient def with the same id but different color or properties 2. In each SVG, refer to the gradient via 'url(#gradient-id)', e.g. as a fill attribute 3. Define and use a font-face that attempts to load a font URL (does not need to resolve to a real file) What is the expected behavior? Each SVG should refer to its locally-defined gradient What went wrong? Both SVGs refer to the last gradient defined. This unexpected behavior only occurs if the document CSS attempts to load a font resource. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 55.0.2883.95 Channel: stable OS Version: OS X 10.11.6 Flash Version: Shockwave Flash 24.0 r0 I first noticed this when hiding one of two duplicate SVGs in a HTML document via javascript. The second SVG's enclosing container was hidden with 'display: none', and because of this bug, the gradient fill of the first SVG disappeared as well.
,
Jan 11 2017
(The 'display: none' issue is issue 448169 .)
,
Mar 7 2017
Gradients are not scoped to the SVG fragment they appear in, but rather to the document (or their shadow root if they appear in one.) This is consistent, and can be compared to, how getElementById works. I.e the "right" gradient to refer to in this case would be the first one (the one with a red stop.) So both <path> using the same gradient is not a bug, but them using the last rather than the first is. The "first vs. last" issue was fixed by 533d683571c860e69bb3ecaf6214c5ceed25a808 ( https://crbug.com/454767#c18 ) |
|||
►
Sign in to add a comment |
|||
Comment 1 by nyerramilli@chromium.org
, Jan 11 2017