One row of pixels of scrolled content is painted on top of the scrolltainer's border
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr140 | --- | unaffected |
| firefox-esr153 | --- | unaffected |
| firefox154 | --- | wontfix |
| firefox155 | --- | wontfix |
| firefox156 | --- | fixed |
People
(Reporter: caleb, Assigned: gw, NeedInfo)
References
(Regression)
Details
(Keywords: nightly-community, regression)
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:154.0) Gecko/20100101 Firefox/154.0
Steps to reproduce:
TLDR: https://jsfiddle.net/pk3ymzq0/
I'm almost certain this worked in Firefox 153.
- A scrolltainer with a 1px border like red
- Position the scrolltainer in between pixels, such as with a div of height: 0.5px before it
- Content that scrolls, with a color like black
- Scroll down
Actual results:
1px of content paints on top of the border. I recommend using a screen magnifier since the effect is subtle (see attached screenshot).
Expected results:
The padding area should be the clipping region
Comment 1•6 days ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, but is not confident enough to move the bug to that component.
Comment 2•5 days ago
|
||
Regression window:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=04da9ebe85a302d5e1cbe26e45cf14026e080ee0&tochange=b6943dbb3d8b5954335a0b837ef4ef9f48ef7c3a
Updated•5 days ago
|
Comment 3•5 days ago
|
||
Set release status flags based on info from the regressing bug 2055145
:gw, since you are the author of the regressor, bug 2055145, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
Updated•5 days ago
|
| Assignee | ||
Comment 4•4 days ago
|
||
Could you attach your about:support since this likely depends on a number of factors like resolution, scaling ratio etc.
| Assignee | ||
Comment 5•3 days ago
|
||
Bug 2055145 made a text run round its clips out to the device grid, and
bug 2056856 extended that to both axes for ancestor clips. An overflow clip sits
flush with the inner edge of its container's painted border box, so rounding it
outward spills a whole device row or column of scrolled content over that border.
Exact is correct: a text clip is applied by clamping the glyph quad's geometry,
with no coverage term, so it resolves at the pixel centre - the same grid the
container's snapped geometry landed on. Round-out moves it a whole pixel off that
grid, always in the spilling direction.
So leave a device-space prim's clips exact, as before bug 2055145. ClipSnap
collapses to Nearest / Exact and SnapRounding::RoundOutNonSubpx goes away; the
bounding rect still rounds out.
Replaces the bug 2055145 wrench test with one for this bug, drops the eight mac
fuzzy annotations it added, and restores the four expectations bug 2056856
removed.
Updated•3 days ago
|
| Assignee | ||
Comment 6•3 days ago
|
||
This patch resolves the bug - it slightly regresses one other case, but in a better way than this issue. I'm working on a more principled fix that will handle both cases, but it seems best to land this in the interim.
Comment 8•2 days ago
|
||
| bugherder | ||
Description
•