1849130 - clip-path on SVG content should default to using the stroke-box

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Philip Rogers]

Attachment: test.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36

Steps to reproduce:

In the attached testcase we have 3 stroked green boxes with clip-paths of "inset(0)", "inset(0) border-box", and "inset(0) stroke-box". These should all render the same due to the following lines in http://www.w3.org/TR/css-masking-1/#the-clip-path:

1. If no reference box is specified, the border-box will be used as
   reference box.
2. For SVG elements without an associated CSS layout box, the used
   value for ... border-box and margin-box is stroke-box.

I found this while working on bringing Chromium's clip-path implementation up to speed and found no engines agree on this. I plan to land two new WPT tests covering this behavior (css/css-masking/clip-path-svg-content/clip-path-inset-stroke-001.svg and css/css-masking/clip-path-svg-content/clip-path-inset-stroke-002.svg).

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::SVG' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Robert Longson [:longsonr]]

Attachment: Bug 1849130 - clip-path on SVG content should default to using the stroke-box r=emilio

Comment 3

[Robert Longson [:longsonr]]

https://treeherder.mozilla.org/jobs?repo=try&revision=cef8ad9d7000bc2c9db8210c84b41f75a5afb049

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0689f8bf5ca7
clip-path on SVG content should default to using the stroke-box r=emilio

Comment 6

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/0689f8bf5ca7

Comment 7

[Alexandru Ionescu (needinfo me) [:alexandrui]]

(In reply to Cristian Tuns from comment #6)

https://hg.mozilla.org/mozilla-central/rev/0689f8bf5ca7

== Change summary for alert #39387 (as of Sun, 27 Aug 2023 02:54:15 GMT) ==

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)
19%	google-search-restaurants SpeedIndex	android-hw-a51-11-0-aarch64-shippable-qr	warm webrender	241.05 -> 194.84
17%	booking SpeedIndex	android-hw-a51-11-0-aarch64-shippable-qr	warm webrender	853.99 -> 705.82
13%	wikipedia SpeedIndex	android-hw-a51-11-0-aarch64-shippable-qr	warm webrender	239.28 -> 209.25
12%	booking SpeedIndex	android-hw-a51-11-0-aarch64-shippable-qr	cold webrender	1,554.51 -> 1,370.02
12%	google-maps SpeedIndex	android-hw-a51-11-0-aarch64-shippable-qr	warm webrender	300.78 -> 265.98
...	...	...	...	...
5%	bing ContentfulSpeedIndex	android-hw-a51-11-0-aarch64-shippable-qr	warm webrender	289.23 -> 274.46

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=39387

Comment 8

[Mayank Bansal]

seems a little improbable that this bug would have lead to these large perf improvements (does wikipedia test even have that many SVG's?).
Can you recheck please?

Comment 9

[Alexandru Ionescu (needinfo me) [:alexandrui]]

Sorry for the late reply, I was looking into it and I'm searching for the commit that caused the improvement, thanks!