Bug 129246 – -webkit-clip-path wrong offset for clipPath references

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Dirk Schulze]

Created attachment 225035 [details]
Example - should be a perfect circle

If -webkit-clip-path references a <clipPath> element the offset is from the top left of the viewport, not of the HTML element.

This changes once a CSS transform is specified. Then the offset is correct. -webkit-transform: translate(0px, 0px)

[Dirk Schulze]

The example makes use of clipPathUnits="userSpaceOnUse". All units an percentage are resolved in the viewport of the <clip-path> element (wrongly btw). All objects within <clipPath> are sized and positioned in this coordinate space. The these objects are just mapped to the coordinate space of the clipped object.

This causes the wrong offset and strange behavior of clipping paths with percentage values.

[Dirk Schulze]

https://codepen.io/krit/pen/xjMRWM

[Dirk Schulze]

Created attachment 340807 [details]
Patch

[Simon Fraser (smfr)]

Comment on attachment 340807 [details]
Patch

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

> Source/WebCore/rendering/RenderLayer.cpp:4179
> +            downcast<RenderSVGResourceClipper>(*element->renderer()).applyClippingToContext(renderer(), svgReferenceBox, paintingInfo.paintDirtyRect, context);

Does hasTagName(SVGNames::clipPathTag) mean that the renderer is always a RenderSVGResourceClipper? (I know the existing code did this.). I would feel happier with an is<> check, otherwise this code will release-assert.

[Dirk Schulze]

Created attachment 343747 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 343747 [details]
Patch for landing

Clearing flags on attachment: 343747

Committed r233287: <https://trac.webkit.org/changeset/233287>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/41550953>