47 bytes, text/x-phabricator-request
|Details | Review|
User Agent: Mozilla/5.0 (Android 7.1.1; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0 Steps to reproduce: 1. Open https://www.mozilla.org/en-US/firefox/ 2. Zoom in 3. Enter fullscreen of a video 4. Exit Actual results: The page is zoomed out Expected results: The page should still be zoomed in
I can reproduce this intermittently. It looks like there may be a race condition between the code to restore the original zoom level that was added in bug 1493976, and some other code that is setting the zoom level.
(In reply to Botond Ballo [:botond] from comment #1) > and some other code that is setting the zoom level Specifically, APZCCallbackHelper::UpdateRootFrame() .  https://searchfox.org/mozilla-central/rev/8f0db72fb6e35414fb9a6fc88af19c69f332425f/gfx/layers/apz/util/APZCCallbackHelper.cpp#318
Component: General → Panning and Zooming
Product: Firefox for Android → Core
Version: Firefox 65 → 65 Branch
We take this branch in NotifyLayersUpdated()  which has a comment that says: // Any change to the pres shell resolution was requested by APZ and is // already included in our zoom; This is no longer true in light of bug 1493976.  https://searchfox.org/mozilla-central/rev/8f0db72fb6e35414fb9a6fc88af19c69f332425f/gfx/layers/apz/src/AsyncPanZoomController.cpp#4323
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
The tracking is done using nsAtom origins, similarly to how updates to the scroll offset are tracked. Currently, APZ still uses some heuristics to deduce that the main thread originated a resolution change in some cases, but the intention is to try to remove those and rely only on this mechanism in the furture.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/79e8494d5df5 Track more accurately when the main thread originates a resolution change. r=kats
You need to log in before you can comment on or make changes to this bug.