Bug 92254 – Horizontal and vertical lines disappear when clipped by a clip that follows

• Component: SVG
• Status: RESOLVED CONFIGURATION CHANGED

[Stephen Chenney]

The easiest way to explain this is with an example:

<svg version="1.1" width="200" height="200" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
 <g>
   <path clip-path="url(#p89235380d8)" d="M50 100 L150 100" style="fill:none;stroke:#000000;stroke-width:1.5;"/>
 </g>
 <g>
   <path clip-path="url(#p89235380d8)" d="M100 50 L100 150" style="fill:none;stroke:#000000;stroke-width:1.5;"/>
 </g>
 <defs>
  <clipPath id="p89235380d8">
   <rect height="120" width="120" x="40" y="40"/>
  </clipPath>
 </defs>
</svg>

The paths appear, then disappear one frame later when the clip is found and applied. If the clip comes first in the file, everything works fine.

[Stephen Chenney]

Created attachment 154356 [details]
Simpole test case

This is the test case to modify for a LayoutTest. I have only looked at Chrome - this could have something to do with Skia.

[Stephen Chenney]

For tracking, the Chrome bug is http://code.google.com/p/chromium/issues/detail?id=135321

[Stephen Chenney]

Created attachment 157490 [details]
Patch

[Dirk Schulze]

Comment on attachment 157490 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=157490&action=review

> Source/WebCore/rendering/svg/RenderSVGResourceClipper.cpp:326
>      // Resource was not layouted yet. Give back the boundingBox of the object.
>      if (selfNeedsLayout())
> -        return object->objectBoundingBox();
> +        return object->strokeBoundingBox();

I have to check if it is right, but at least the comment needs to be updated.

[Dirk Schulze]

Comment on attachment 157490 [details]
Patch

I wonder if we didn't need the bounding box for the calculation of a clipPath on a clipPath: <clipPath clip-path="url(#otherClipPath)"></clipPath> and the other clipPath takes the bounding box of the first one for it's calculation. Can you check that please?

[Anders Carlsson]

Comment on attachment 157490 [details]
Patch

Clearing review flag on patches from before 2014. If this patch is still relevant, please reset the r? flag.

[Ahmad Saleem]

I am unable to reproduce this issue using attached test case in Safari 15.5 / Safari Technical Preview 148 on macOS 12.4. Safari matches with other browsers like Firefox Nightly 104 and Chrome Canary 105. I think this can be marked as "RESOLVED CONFIGURATION CHANGED" since similar happened to linked Chrome bug in Comment 02 and it got fixed due to some other code changes or fixes. Thanks!