Incorrect clipping behaviour of fixed element inside sticky element
Categories
(Core :: Web Painting, defect, P3)
Tracking
()
People
(Reporter: botond, Unassigned)
References
()
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
Reporter | ||
Updated•6 years ago
|
Reporter | ||
Updated•6 years ago
|
Comment 1•6 years ago
|
||
Updated•6 years ago
|
Comment 2•6 years ago
|
||
I think this bug might caused by the change 1 (in bug 1404181) to, and later (in bug 1426653) removal of, nsFrame::SchedulePaint() call, when mAPZFocusSequenceNumber changes. Adding this line back seems to fix the testcase locally (with some flickering due to constant repainting).
Unfortunately, I doubt that this is the right way to fix this. The root cause is probably a wrong display port, frame, or clip rect size, when the scrolled item is built.
Updated•6 years ago
|
Reporter | ||
Comment 3•6 years ago
|
||
I turned the testcase into a reftest.
Some brief investigation shows that transforms are being set correctly in AsyncCompositionManager. In the reftest, we have a reftest-async-scroll-y=1000, so the sticky element (which is within its scrolling range) gets a transform of -1000, and the fixed element inside it gets a compensating transform of +1000 to keep it fixed.
The problem seems to be that in between those two transforms (at the level of the fixed container layer, which has the +1000 transform applied to it while inheriting the -1000 from its parent), the content is clipped to the viewport, which clips away the border which is "offscreen" at this level.
Reporter | ||
Comment 4•6 years ago
|
||
It seems to me that applying a viewport clip to a fixed layer that's inside something that can scroll (like the sticky layer in this case) is incorrect. That suggests the issue is with the clip / ASR computation code in Layout. I'd rather not touch that until after the cleanup planned in bug 1511419.
Reporter | ||
Comment 5•6 years ago
|
||
(Based on comment 2, bug 1404181 is a red herring. The change made there was just causing us to repaint more often, thereby avoiding a situation where we have a large enough async scroll offset for the content to be outside the viewport clip.)
Updated•6 years ago
|
Comment 7•6 years ago
|
||
Matt, this is a P2 without an assignee. Can you please find an assignee for this?
Reporter | ||
Comment 8•6 years ago
|
||
(FWIW, I think this can be a P3 in the absence of a real-world website where this issue occurs.)
Comment 9•6 years ago
|
||
(In reply to Neha Kochar [:neha] from comment #7)
Matt, this is a P2 without an assignee. Can you please find an assignee for this?
I'll make this P3 as Botond suggested, but in general requiring P2s to be assigned isn't something we've been aiming for in Web Painting.
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Reporter | ||
Comment 11•3 years ago
|
||
WONTFIX as this bug only occurs with non-WR.
Updated•3 years ago
|
Updated•2 years ago
|
Description
•