mask-composite doesn't work properly without mask-repeat: no-repeat or a border-radius > padding (or border-width)
Categories
(Core :: Web Painting, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox88 | --- | fixed |
People
(Reporter: ana.tudor.lhnh, Assigned: emilio)
References
Details
(Keywords: regressionwindow-wanted)
Attachments
(5 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36
Steps to reproduce:
Trying to get a gradient frame using masking.
- Set a non-zero
padding
or (transparentborder
) on the element with the gradient.
padding: 1em;
width: 8em; height: 8em;
background: linear-gradient(gold, indigo) border-box;
- Set a mask consisting of two fully opaque layers, one limited to
content-box
bymask-clip
, the other one covering the entireborder-box
.
--grad: linear-gradient(red, red);
mask:
var(--grad) content-box,
var(--grad)
- Set
mask-composite: exclude
- this should basically XOR the two layers, leaving just the frame created by thepadding
(orborder
) visible.
Actual results:
Everything disappears when setting mask-composite: exclude
unless:
a) we also set mask-repeat: no-repeat
OR
b) we also set a border-radius
value that's greater than that of the padding
(or border-width
) - if the border-radius
is smaller or equal to the padding
, this doesn't work
Reduced test case https://codepen.io/thebabydino/pen/ZEBmLQQ
Expected results:
We should get a gradient frame. This is what happens in Chrome.
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
Assignee | ||
Comment 3•4 years ago
|
||
This worked briefly (sometime between firefox 55 and 58). Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=307a7a34013060a6a1e87dfbb911f058d0781a2e&tochange=57f68296c350469d73d788eb3695a898947b4acb
There's a lot of stuff there because we don't have all those intermediate builds, but from that list bug 1373750 looks particularly suspicious.
Assignee | ||
Comment 4•4 years ago
|
||
The code was unconditionally passing the border area, which is very
suspect, and causes us to repeat the mask incorrectly towards the
border, drawing nothing.
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 5•4 years ago
|
||
The code is unconditionally passing the border area, which is very
suspect, but it's not problematic because it only cares of getting the
dest rect (which doesn't depend on the background clip).
Depends on D107747
Assignee | ||
Comment 6•4 years ago
|
||
The code was correctly computing currentLayerClipState
for the right
layer, but then it was calling PrepareImage with clipState
rather than
currentLayerClipState
, which in the case of masks only contains the
clip for the bottom layer. This can cause background-repeat to
over-extend, causing the issue.
Depends on D107757
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/47e251fa2c9f Simplify GetInsideClipregion(). r=mstange https://hg.mozilla.org/integration/autoland/rev/2f69ef9296a3 Add a comment and clean up nsDisplayMasksAndClipPaths constructor. r=mstange https://hg.mozilla.org/integration/autoland/rev/350441a59119 Use the right clip for subsequent mask layers. r=mstange
Updated•4 years ago
|
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/28006 for changes under testing/web-platform/tests
Comment 9•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/47e251fa2c9f
https://hg.mozilla.org/mozilla-central/rev/2f69ef9296a3
https://hg.mozilla.org/mozilla-central/rev/350441a59119
Upstream PR merged by moz-wptsync-bot
Description
•