Scrolling to input in desktop viewport is broken in some cases
Categories
(Core :: Panning and Zooming, defect, P2)
Tracking
()
People
(Reporter: agi, Assigned: botond)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files)
While looking at Bug 1667497, we noticed there's a different problem with zoomToFocusedInput
. The testcase can be found here https://bugzilla.mozilla.org/show_bug.cgi?id=1667497#c1
Assignee | ||
Comment 1•4 years ago
|
||
I've looked into this a bit. A zoom animation with the correct destination is started, but then gets cancelled mid-animation (near the beginning actually) due to a scroll update from the main thread.
I haven't tracked down what's causing the scroll update. One theory is that it's from the ScrollContentIntoView
call in ZoomToFocusedInput()
, and the IPC message for the transaction carrying the scroll update is racing with the IPC message carrying the ZoomToRect
call, but I haven't confirmed this yet.
Assignee | ||
Comment 2•4 years ago
|
||
diagnosis |
(In reply to Botond Ballo [:botond] from comment #1)
I haven't tracked down what's causing the scroll update. One theory is that it's from the
ScrollContentIntoView
call inZoomToFocusedInput()
, and the IPC message for the transaction carrying the scroll update is racing with the IPC message carrying theZoomToRect
call, but I haven't confirmed this yet.
I've now confirmed that this is what's happening. Even though ScrollContentIntoView
is performing instant scrolling, it queues up a scroll update to APZ that rides the next transaction. The ZoomToRect
call uses its own IPC message which arrives first, starts the animation, and then the scroll update cancels it.
My best idea for how to fix this is to delay the ZoomToRect
call to a post-refresh observer the way we do with SetTargetAPZC
here.
Updated•4 years ago
|
Comment 3•4 years ago
|
||
A post-refresh observer seems reasonable, but maybe we should try to restrict it to the case where ScrollContentIntoView actually does useful work (which should be infrequent - in most cases the user will focus an input element by tapping on something already visible). Otherwise we will be adding some avoidable latency to the zoom animation start which can confuse users into wondering whether or not their tap actually worked.
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
Assignee | ||
Comment 5•4 years ago
|
||
ZoomToFocusedInput calls ScrollContentIntoView() which may queue up
one or more main-thread scroll position updates that get sent to
APZ as part of the next transaction.
If such updates were produced, we want the ZoomToRect call to arrive
at APZ after the updates, otherwise the updates can cancel the
zoom animation that APZ starts in response to the ZoomToRect.
Depends on D93897
Updated•4 years ago
|
Updated•4 years ago
|
Comment 10•4 years ago
|
||
Backed out 3 changesets (Bug 1669588) for causing mochitest failures in test_group_zoomToFocusedInput.html
Backout link: https://hg.mozilla.org/integration/autoland/rev/b0c83856ebcf4548dfaf208d32c58380262b2628
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=319327093&repo=autoland&lineNumber=12144
Assignee | ||
Comment 11•4 years ago
|
||
This variable is set from the compositor thread, and read from both
the sampler thread (e.g. when sampling animations) and the
controller thread (e.g. during input block creation), so access to
it needs to be synchronized.
Depends on D93898
Assignee | ||
Updated•4 years ago
|
Comment 12•4 years ago
|
||
Comment 13•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/937bd02f15aa
https://hg.mozilla.org/mozilla-central/rev/b0f29632ca85
https://hg.mozilla.org/mozilla-central/rev/a7003d573886
Updated•4 years ago
|
Description
•