Assert that the resolution is 1 whenever we skip building an async zoom container
Categories
(Core :: Panning and Zooming, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox132 | --- | fixed |
People
(Reporter: botond, Assigned: botond)
References
Details
Attachments
(3 files)
In bug 1889017, I discovered that there can potentially be scenarios where we ignore the pres shell resolution during rendering, but don't ignore it during hit testing (see bug 1889017 comment 19 in particular).
This is always a bug, as it means the hit testing behaviour is out of sync with rendering, e.g. taps can be routed to elements which are not visually at the point on the screen that was tapped.
Bug 1889017 fixes a particular case of this, but in this bug I'd like to add a more general assertion that this never happens. Such as an assertion would have helped catch and diagnose bug 1889017 sooner.
Assignee | ||
Comment 1•1 month ago
|
||
Updated•1 month ago
|
Comment 3•1 month ago
|
||
Backed out for causing mochitests crashes.
- Backout link
- Push with failures
- Failure Log
- Failure line: PROCESS-CRASH | MOZ_ASSERT(document->GetPresShell()->GetResolution() == 1.0f) [@ mozilla::nsDisplayListBuilder::UpdateShouldBuildAsyncZoomContainer] | gfx/layers/apz/test/mochitest/mochitest.toml
Assignee | ||
Comment 4•1 month ago
|
||
The assertion failure happens when we try to run helper_touch_drag_root_scrollbar.html in the apz.allow_zooming=false configuration on Android.
apz.allow_zooming=false
is known to be quite broken on Android, and this assertion failure is highlighting why: we will not build an async zoom container (and hence not apply the resolution for rendering purposes), but there is indeed nothing preventing us from unapplying the resolution during hit testing, if one is somehow set. (The assumption is that with apz.allow_zooming=false, the mechanisms that allow the user to set a resolution != 1.0 in the first place are disabled, but this does not consider mobile viewport sizing which can result in a resolution being set automatically.)
Rather than trying to fix apz.allow_zooming=false on Android, I'd rather continue treating this configuration as unsupported, which includes not running tests in this configuration.
Assignee | ||
Comment 5•1 month ago
|
||
Things are looking better on Android with that test disabled in the apz.allow_zooming=false configuration, but there are other assertion failures in desktop tests that need investigation: https://treeherder.mozilla.org/jobs?repo=try&revision=13e77338ee92b67bee176e8fe28ea643d07f7097
Assignee | ||
Comment 6•29 days ago
|
||
The test that was failing on desktop is test_fullscreen_meta_viewport.html
, and the failure actually pointed out a MobileViewportManager
issue similar to the one fixed in bug 1889017: after the resolution has been set to 1.0 by Document::ApplyFullscreen
, it was possible for MobileViewportManager
to stomp on that and set a different resolution due to logic in UpdateResolutionForViewportSizeChange
. That function needs a check for being in fullscreen mode.
Assignee | ||
Comment 7•29 days ago
|
||
Depends on D220201
Assignee | ||
Comment 8•29 days ago
|
||
Depends on D221391
Comment 10•27 days ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0724a828704c
https://hg.mozilla.org/mozilla-central/rev/22ed31f0fff3
https://hg.mozilla.org/mozilla-central/rev/a96239238507
Description
•