2045151 - Mask attribute misbehaving on nested SVG elements

Status: NEW

(Core :: SVG, defect)

Description

[Gouvernathor]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:151.0) Gecko/20100101 Firefox/151.0

Steps to reproduce:

I applied a CSS gradient as the mask of a SVG element within a SVG element.
I also tried going through the mask and mask-image CSS properties.
I also tried using a g inner element rather than a nested SVG element.

See https://jsfiddle.net/s6qhn3gc/6/

It seems to depend on the contents of the inner element : look at the comment, try removing the element, and changing the x and y properties.

Actual results:

The image turns invisible.

Expected results:

There should have been a gradient transparency.

Comment 1

[BugBot [:suhaib / :marco]]

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]]

Looks the same as Chrome to me. Can you please

a) create and attach the simplest possible testcase and
b) attach a screenshot of what you're seeing and what you see in some other renderer (if there is one that displays what you think should be displayed.

Comment 3

[Gouvernathor]

Attachment: three examples of SVG, the midddle one is problematic and cropped for no apparent reason

Comment 4

[Gouvernathor]

My reference is not another renderer, it's the specification (or rather, the MDN explanations), and the fact that the behavior seems erratic.
Notice the cutoff on the numbers on the right, as you change the x and y coordinates of the element where the comment is.

Simpler version of the fiddle.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

I can reproduce the clipping shown in the screenshot. Here's a reduced version that demonstrates the same clipping.

On my machine (Ubuntu 26.04):
Chrome renders "SUCCESS" in the cyan area.
Firefox renders just a little bit of the "S" and nothing after that.

Comment 6

[Daniel Holbert [:dholbert]]

Regression range, with the testcase that I just attached:

INFO: Last good revision: da22155a2dc30dafc93d70f38f6bb8a49248c80f (2016-12-24)
INFO: First bad revision: 1156db49e976173fc3cf90d2126456fd1e2bae4b (2016-12-25)
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=da22155a2dc30dafc93d70f38f6bb8a49248c80f&tochange=1156db49e976173fc3cf90d2126456fd1e2bae4b

In that range, it seems likely this was fallout from bug 1311270 which rewrote a bunch of mask stuff.

Comment 7

[Daniel Holbert [:dholbert]]

Confirming the likely relationship to bug 1311270 (and mask-clip in particular): this CSS rule successfully avoids the issue, in all the jsfiddle testcases here (as well as my attached testcase):

* { mask-clip: no-clip }

So it seems we're having trouble with the default value of this mask-clip property (and its default border-box value, and indeed all values besides no-clip I think). We're getting too small of a clip region.

Comment 8

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1311270