Assign the ASR (active scrolled root) of the anchor to the anchored element
Categories
(Core :: CSS Parsing and Computation, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox147 | --- | fixed |
People
(Reporter: dshin, Assigned: tnikkel)
References
(Blocks 2 open bugs, Regressed 1 open bug)
Details
(Whiteboard: [anchorpositioning:graphics], [wptsync upstream])
Attachments
(7 files, 1 obsolete file)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
| Assignee | ||
Comment 1•7 months ago
|
||
Updated•7 months ago
|
| Assignee | ||
Comment 2•7 months ago
|
||
| Assignee | ||
Comment 3•7 months ago
|
||
This gives an easy way to disable in case of issues and allows toggling for testing purposes (to narrow down if a potential issue is async or main thread scrolling related).
| Assignee | ||
Comment 4•7 months ago
|
||
Being inside an active view transition forces a scroll frame to be inactive.
IsInViewTransitionCapture is set on a stacking context basis. This means that when painting walks from a placeholder frame to its out of flow then IsInViewTransitionCapture follows. But the ASR tree (which we must construct for async scrolling the anchor pos) strictly follows the parent (not the placeholder). So we'd have to do a completely separate walk, and I'm not sure it's worth it. If it turns out to be important we can implement something, or even better just remove that code in DecideScrollableLayer which I'm pretty sure we don't need but I don't want to open that can of worms right now.
| Assignee | ||
Comment 5•7 months ago
|
||
Anchored content can get assigned an ASR that is "far away" from it with no relation in the frame tree. So if something about the ASR changes we need to invalidate the anchored content but that is not straight forward, and not worth it until/unless we find it causing an issue.
| Assignee | ||
Comment 6•7 months ago
|
||
Anchored content can get assigned an ASR that is "far away" from it with no relation in the frame tree. So if something about the ASR changes we need to invalidate the anchored content but that is not straight forward, and not worth it until/unless we find it causing an issue.
Updated•7 months ago
|
| Assignee | ||
Comment 7•7 months ago
|
||
| Assignee | ||
Updated•7 months ago
|
Comment 12•7 months ago
|
||
| Assignee | ||
Comment 13•7 months ago
|
||
It's a single pixel just at the edge of a lower case letter t (two instances in each test).
Comment 14•7 months ago
|
||
Comment 15•7 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/ae3b4e95cd36
https://hg.mozilla.org/mozilla-central/rev/74ae9f86faab
https://hg.mozilla.org/mozilla-central/rev/1c2d8a47374e
https://hg.mozilla.org/mozilla-central/rev/bc2eb1b66aae
https://hg.mozilla.org/mozilla-central/rev/cfd58f087220
https://hg.mozilla.org/mozilla-central/rev/b2284f1c94ea
https://hg.mozilla.org/mozilla-central/rev/227774938f7b
Updated•6 months ago
|
Updated•6 months ago
|
Description
•