Issue metadata
Sign in to add a comment
|
Multiple SVG Elements with clipPaths broken in Chrome 59
Reported by
ro...@botify.com,
Jun 8 2017
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36 Steps to reproduce the problem: Reproduction here: https://jsfiddle.net/eisenbergrobin/mj19fcnr/7/ 1. Draw an <svg> with <defs> for clipPaths, and draw <rect>s using this clipPath 2. Clone the svg using cloneNode(true), and append the clone to the document body 3. Set 'visibility: hidden' on the original node Result: the cloned <svg>'s <rect>s are no longer drawn Expected Result: only the first <svg> is affected by the 'visibility: hidden' - the cloned node stays displayed What is the expected behavior? Expected behaviour is that only the first <svg> is affected by the 'visibility: hidden' - the cloned node stays displayed What went wrong? The second svg's (cloned node) <rects> that use a clipPath are no longer drawn. Did this work before? Yes Chrome 58 handled this correctly. Does this work in other browsers? Yes Chrome version: 59.0.3071.86 Channel: stable OS Version: OS X 10.12.4 Flash Version: This was working in Chrome 58 - confirmed on another computer. Works on Safari and Firefox, broken in Chrome 59.
,
Jun 8 2017
Alright thanks for taking a look, and for the detailed explanation. The fix works fine for me.
,
Jun 8 2017
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by f...@opera.com
, Jun 8 2017The reason this happens is that in the second <svg>, the clip-path in the first is still what's being used (there will be two <clipPath> elements with the same id, which means the first one is picked.) When visibility is toggled on the fragment containing the first <svg>, the children of the <clipPath> are also made invisible [1], yielding an empty clip path. The reason this may have changed is that a bug was fixed that did not trigger repaint properly in cases like this ('visibility' changed on an ancestor of the <clipPath> IIRC.) Gecko doesn't appear to treat <clipPath> children with 'visibility: hidden' according to spec, and for Safari I'd suspect that they still suffer from the bug that was fixed in Blink. This can be "worked around" (fixed) by setting 'visibility' to 'visible' for the clipPath (for example by adding the rule: "clipPath { visibility: visible; }".) [1] "If a child element is made invisible by display or visibility it does not contribute to the clipping path." from https://drafts.fxtf.org/css-masking-1/#ClipPathElement