Fix a race condition where we don't properly handle scroll position updates until we received the proper layersId from the parent process painting
Categories
(Core :: Panning and Zooming, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox125 | --- | fixed |
People
(Reporter: hiro, Assigned: hiro)
References
(Blocks 4 open bugs)
Details
Attachments
(3 files, 3 obsolete files)
The race is the root cause of bug 1841305. And I believe with the fix for the race we can drop a workaround for the same root cause issue in our mochitests introduced in https://hg.mozilla.org/integration/autoland/rev/49393cd5db23 .
Attaching file contains a wpt to cause the race at least on my local Linux box.
Updated•1 year ago
|
Assignee | ||
Comment 1•9 months ago
•
|
||
With restricting to the scroll position updates in the first paint data, fixing the race was so hard. So I'd like to start with the approach with the restriction here in this bug, and later if we could still see this race we can extend the approach to address non-first paint cases.
One caveat is that I can no longer see the test failure attached in comment 0 locally without any changes on the current m-c. That said, the test, after-scrollable-range-shrinkage-004.html surely fails without any changes, but doesn't fail the approach as far as I can tell.
Assignee | ||
Comment 2•9 months ago
|
||
One more note; I saw scroll-behavior-main-frame-root.html failed on a try run which includes both fixes for this bug and bug 1871760, it maybe mean that it's in fact non-first paint cases, but I am not sure. Anyways since then I haven't seen any failures, so I'd go with the current approach for now.
Assignee | ||
Comment 3•9 months ago
|
||
Assignee | ||
Comment 4•9 months ago
|
||
Assignee | ||
Comment 5•9 months ago
|
||
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Comment 6•9 months ago
|
||
Comment on attachment 9380332 [details]
Bug 1845646 - Drop the workaround introduced in bug 1437295. r?botond
Revision D201922 was moved to bug 1881985. Setting attachment 9380332 [details] to obsolete.
https://hg.mozilla.org/mozilla-central/rev/1d4a8f6f0ca8
https://hg.mozilla.org/mozilla-central/rev/76a3e268757c
Assignee | ||
Comment 12•8 months ago
|
||
And add a caveat about windowSoftInputMode in a document.
We implement interactive-widget [1] in a way that the content is laid out as if
the window doesn't get resized even if the application window gets resized by
the software keyboard. To make this way work, using adjustResize
is mandatory.
An alternative approach to implement it is to change windowSoftInputMode value
depending on each content's interactive-widget value in each Android Activity,
i.e., set to adjustResize
on interactive-widget=resizes-content
mode, set to
adjustUnspecified
on interactive-widget=resizes-visual
or on
interactive-widget=overlays-mode
. It will force applications to do more work.
[1] https://drafts.csswg.org/css-viewport/#interactive-widget-section
Assignee | ||
Comment 13•8 months ago
|
||
Comment 14•8 months ago
|
||
Comment on attachment 9390414 [details]
Bug 1845646 - Explicitly set android.windowSoftInputMode to GeckoView test runner. r?#geckoview-reviewers
Revision D204165 was moved to bug 1831649. Setting attachment 9390414 [details] to obsolete.
Comment 15•8 months ago
|
||
Comment on attachment 9390418 [details]
Bug 1845646 - Tweak viewport stuff while the dynamic toolbar is moving for interactive-widget. r?botond
Revision D204169 was moved to bug 1831649. Setting attachment 9390418 [details] to obsolete.
Description
•