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 future.
Differential Revision: https://phabricator.services.mozilla.com/D13741
--HG--
extra : moz-landing-system : lando
Adds an |UpdateType| parameter to UpdateResolution() to better separate the
pre-reflow and post-reflow logic.
Differential Revision: https://phabricator.services.mozilla.com/D13314
--HG--
extra : moz-landing-system : lando
* Call SetResolutionAndScaleTo() in just one place
* Call UpdateVisualViewportSize() in UpdateResolution() rather than
requiring the caller to do it (and on non-first paints, only call it
if the resolution has actually changed)
Differential Revision: https://phabricator.services.mozilla.com/D13313
--HG--
extra : moz-landing-system : lando
* Introduce helpers for converting between zoom and resolution
* Perform calculations in terms of zoom rather than resolution
Differential Revision: https://phabricator.services.mozilla.com/D13312
--HG--
extra : moz-landing-system : lando
What we need to do here is to scale down the document as if the document was pinched in
to fit the contents to screen width when all the following conditions are met.
- it's the first paint for the document
- no initial-scale is specified in meta viewport tags
- no mRestoreResolution hasn't set
- the content width is wider than the initial viewport width
Depends on D10196
Differential Revision: https://phabricator.services.mozilla.com/D10197
--HG--
extra : moz-landing-system : lando
We can't have a null content in
ScrollbarActivity::StopListeningForScrollAreaEvents, because only viewport
frames have a null GetContent().
MozReview-Commit-ID: 9iAg0ivVqqG
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
When going back/forward through a tab's session history, the saved resolution from the LayoutHistoryState is set on the PresShell before first paint. On Fennec, this means that it is subsequently going to be overwritten by the MobileViewportManager's default zoom calculation.
To fix this, we make use of the MVM's feature to set a "restored" resolution that will then be taken into account on first paint.
MozReview-Commit-ID: 43o97M6fiaZ
--HG--
extra : rebase_source : 0dda351784f3f5e3d88ec3e176b73974e96b71b7
When going back/forward through a tab's session history, the saved resolution from the LayoutHistoryState is set on the PresShell before first paint. On Fennec, this means that it is subsequently going to be overwritten by the MobileViewportManager's default zoom calculation.
To fix this, we make use of the MVM's feature to set a "restored" resolution that will then be taken into account on first paint.
MozReview-Commit-ID: 43o97M6fiaZ
--HG--
extra : rebase_source : 45d29057de137cb306617481311622c6ca620fa3
The class PresShell doesn't have ns-prefix, so it's better to drop ns-prefix
in the file names to avoid confusion.
MozReview-Commit-ID: IljxsF5CVjh
--HG--
rename : layout/base/nsPresShell.cpp => layout/base/PresShell.cpp
rename : layout/base/nsPresShell.h => layout/base/PresShell.h
extra : rebase_source : e73a6873f360a7223d87bd22d9854fc9603c499f
The mobile session store saves the current document resolution in order to restore the previous zoom level when restoring a page. If the display width has changed since the session data was captured (e.g. because the device was rotated), the resolution might have to be scaled appropriately.
Currently, the session store does this scaling by itself by comparing the stored and current window widths, however this implementation is slightly simplified and doesn't cover all use cases, which means some pages can be restored at a wrong zoom level after rotation. To correctly cover all cases, the session store would have to compare viewport widths, too.
Because the MobileViewportManager doesn't wait for the session store to set the restore resolution, the latter has to call setRestoreResolution() as early as possible in order to guarantee that the restore resolution is set before the first paint of the document. Therefore the session store currently calls this after receiving a LocationChange notification. However at that time, the correct viewport for the current document is not yet available, which means the resolution cannot be recalculated by the session store at that point.
Therefore, this patch changes the approach taken and lets the MVM handle all resolution calculations instead. The session store now simply passes the stored previous display dimensions along with the previous document resolution to the MVM, which can then compare them to the current display and viewport widths and scale the resolution appropriately before using it during first paint.
MozReview-Commit-ID: IGxWw87yftK
--HG--
extra : transplant_source : e%8D%BD%26%D2%C3%8E5%E3%2B%C0t%BA%DB%C1%BBs%3F%13%1F
We'll want to use this during first-paint, too, in order to correctly scale the resolution as received by the session store if we're restoring a previous tab. Therefore we extract this code into a separate helper function.
MozReview-Commit-ID: KCdvmyrP4mJ
--HG--
extra : transplant_source : c%BD%99%9D%F8%9EW%D2%8B%BD%E0a%82%ED%3B%EE%EF%ACl%D6
This makes it clearer whether we're just checking if a displayport exists,
or we're actually consuming its value.
--HG--
extra : source : 70bb222e860669a6cf6e803dbd57f088ca4fbc04