Ensure scroll restoration works properly with a visual viewport enabled
Categories
(Core :: Panning and Zooming, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox79 | --- | fixed |
People
(Reporter: kats, Assigned: kats)
References
Details
Attachments
(2 files)
When there's a visual viewport set, the mechanism for updating the visual scroll position from the main thread is a bit roundabout. Specifically, the call here sets a "pending scroll update" which is sent to APZ on the next repaint. And then when APZ sends back the next repaint request, that's when the main-thread actually updates the local visual scroll offset.
This is a problem because the scroll restoration code immediately reads back the visual scroll position here and expects it to be up-to-date, in the case of an incremental scroll restoration. Because of the above roundabout mechanism, it is often zero instead. This can cause scroll restoration to not work properly, which manifests as some tests failing when apz.allow_zooming is enabled.
|
Assignee | |
Comment 1•5 years ago
|
||
|
|
Assignee | |
Comment 2•5 years ago
|
||
Depends on D79885
|
|
Assignee | |
Comment 3•5 years ago
|
||
mLastPos is supposed to be updated by querying the visual viewport offset from
the presShell. However because of the way the visual viewport offset is updated,
this doesn't return a nonzero value until after APZ sends back a repaint request.
So this patch modifies the query to also check if there's any pending visual
viewport offset update being sent from the main thread, and use that. It also
modifies the scroll restoration code to request a properly clamped visual
scroll offset, so that the value stored as "pending" is not just the unclamped
restore destination.
Depends on D80038
|
||
Comment 5•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/655415177f72
https://hg.mozilla.org/mozilla-central/rev/656ee9fed2f9
Description
•