There's two code changes in this patch:
- The update to the visual viewport that was happening just before positioning
the fixed items gets moved to happen after determining the scrollbars for
the root scrollframe. This moves it a little bit earlier, to basically the
earliest point at which the visual viewport can actually be computed, since
it depends on the presence of the root scrollframe's scrollbars.
More importantly, this change sets the visual viewport without checking to
see if one was already set, as the old code did. This means every reflow
of the root scrollframe on a presShell with an MVM will now have a visual
viewport set. Previously the visual viewport would only get set for the first
time when the MVM got a load or first-paint event, and then would get updated
for subsequent reflows. The net effect here is that the visual viewport is
set earlier, and this can sometimes eliminate extra reflows from after the
load event, because everything is already in a consistent state.
- The NotifyResizeReflow call to MVM is replaced by a NotifyReflow call that
runs before every reflow, instead of just on resizes. Note that the
NotifyReflow also doesn't update the visual viewport like NotifyResizeReflow
used to do, because that is taken care of by the above-mentioned code change
to set the visual viewport.
This is desirable because there are things that run during reflow that attempt
to read the display size from the MVM, and they were getting a zero size
for reflows that happened before the first resize or load/first-paint events.
Now they get a valid display size on every reflow, and so again this allows
fewer overall reflows as the code converges to a stable state faster.
Together these changes ensure that every reflow has access to up-to-date
properties (display size, mobile viewport size, visual viewport size) from the
MVM. This eliminates unnecessary reflows because of out-of-order computations
based on stale values and such. Therefore the number of reflows goes down,
which is reflected by the changes to the crashtest assertion counts.
Differential Revision: https://phabricator.services.mozilla.com/D81375
Instead of having callers compute the cssToDev and pass it to the zoom/
resolution conversion functions, we can just do it in those functions directly.
Differential Revision: https://phabricator.services.mozilla.com/D80939
This is a hard diff to read but fundamentally a pretty simple patch. The old
UpdateResolution function had a giant if condition in the middle conditioned
on the update type. Inside the ViewportSize branch there was a further nested
if conditioned on mIsFirstPaint. The function got split into three, with each
new function holding one of the three main blocks of code, along with a copy
of the stuff before and after the if condition. And then I simplified each
function individually to remove unnecessary variables, add some early-exits
and reduce nesting levels, etc.
Depends on D80937
Differential Revision: https://phabricator.services.mozilla.com/D80938
This removes the two parameters to ShrinkToDisplaySizeIfNeeded and corresponding
parameters passed to UpdateResolution. The call site in nsGfxScrollFrame
gets the arguments from the MVM itself, so it seems silly to be getting things
from the MVM just to pass it back in. The other call sites are already in theMVM.
This change might be slightly less efficient because it re-computes the viewport
info when the caller might already have it but this isn't a hot code path so
I'm not too concerned.
Differential Revision: https://phabricator.services.mozilla.com/D80937
There are two parts here. One is the "backstop" in the scrollframe's
ReflowFinished callback, that recomputes the visual viewport size if layout
scrollbars are being used in the root scrollframe. This ensures that the
visual viewport gets resized properly after a reflow, possibly at the expense
of a second reflow to reposition fixed-pos items.
There is also an update to the visual viewport during the reflow itself, after
we have reflowed the in-flow contents (including the root scrollframe) but
before we reflow the fixed-pos items. This allows us to avoid the second reflow
by using the new visual viewport for positioning the fixed-pos items correctly.
This early reflow also skips marking things for a second reflow.
This patch fixes a problem described in bug 1644271 comment 2, among other
things. Specifically, it ensures that when the scrollbar properties (e.g.
maxpos, minpos) are computed, they are computed using an up-to-date visual
viewport size. The up-to-date visual viewport size correctly excludes the space
taken up by non-overlay scrollbars, which wasn't happening without this patch.
Depends on D80039
Differential Revision: https://phabricator.services.mozilla.com/D80040
This is important because if the apz.allow_zooming pref is enabled (and
eventually even without that pref), VisualViewportOnly-type MVMs do set
the visual viewport size based on the display size and zoom, and so need
to be updated when those change.
It's also important to keep the mMobileViewportSize updated and in sync
with the display size, because it may get used via ComputeIntrinsicResolution
when fullscreening.
Differential Revision: https://phabricator.services.mozilla.com/D79594
This is important because if the apz.allow_zooming pref is enabled (and
eventually even without that pref), VisualViewportOnly-type MVMs do set
the visual viewport size based on the display size and zoom, and so need
to be updated when those change.
Differential Revision: https://phabricator.services.mozilla.com/D79594
The MVM is needed for both handling of meta-viewport tags and APZ zooming.
However, the set of functionality needed in the two modes are not the same.
This patch adds a mechanism to create an MVM with a flag that lets it know
which mode it is operating in. Eventually we may want to split this into two
or more classes but for now this seems like a reasonable way forward.
The flag is currently set on the MVM on creation based on whether or not the
meta-viewport support is needed. There's no code that meaningfully *uses* the
flag yet, so this patch should have no functional change. The bulk of the
patch is ensuring that we appropriately destroy and re-create the MVM if the
flag required changes.
Differential Revision: https://phabricator.services.mozilla.com/D79224
On Chrome, visual viewport resize event is fired repeatedly during dynamic
toolbar transitions and visual viewport height obtained by the VisualViewport
API is also changed, but in terms of layout the height value is never used
until the dynamic toolbar height reaches to zero or is changed from zero.
The height used at the time is the height for vh units when the toolbar height
reaches to zero and the ICB height when the toolbar height is changed from zero.
To do so, we need to have another visual viewport size in parallel to the
original one and use them depending on situations.
Differential Revision: https://phabricator.services.mozilla.com/D52338
--HG--
extra : moz-landing-system : lando
This patch changes remaining things under `layout/`. However, there are some
places which still need to use `nsIPresShell`. That will be fixed in a
follow up bug.
Differential Revision: https://phabricator.services.mozilla.com/D27477
--HG--
extra : moz-landing-system : lando
elementFromPoint-002.html, elementFromPoint-003.html and dialog-showModal.html
use document.elementFromPoint with a given point which is calculated from the
value returned by getBoundingClientRect() for a 100% width element. Before
this change, the given point is outside of view because there is no viewport
meta tag in the documents so that elementFromPoint fails. After this change, the
documents fit to the visual viewport so that elementFromPoint works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D16155
--HG--
extra : moz-landing-system : lando
Currently the MobileViewportManager leaves somethings permanently changed
even after it is destroyed: it may have changed the resolution of
the Document, and it may have set a fixed size for the visual viewport.
Both of these changes need to be un-done to return to normal display of
the Document.
Differential Revision: https://phabricator.services.mozilla.com/D17999
--HG--
extra : source : 088dc24eabc75eea96301d50550e0a8817f5f809
Currently the MobileViewportManager leaves somethings permanently changed
even after it is destroyed: it may have changed the resolution of
the Document, and it may have set a fixed size for the visual viewport.
Both of these changes need to be un-done to return to normal display of
the Document.
Differential Revision: https://phabricator.services.mozilla.com/D17999
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
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
Need to add #includes "nsPresContext.h" and "nsThreadUtils.h" in
PresShell.h, and "nsViewportInfo.h" in MobileViewportManager.h to compile.
MozReview-Commit-ID: F8bmOwllOiH
--HG--
extra : rebase_source : cacbb30d854c68ea720f849d03b649bbd3c5da03
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
Razvan Maries
Botond Ballo
Hiroyuki Ikezoe
Kartikaya Gupta
Bogdan Tara
Brad Werth
Masayuki Nakano
Hiroyuki Ikezoe
shindli
Oana Pop Rus
Emilio Cobos Álvarez
Cameron McCormack
Sylvestre Ledru
Arika Arnzen
Daniel Varga
Boris Zbarsky
Daniel Holbert
Jan Henning
Sebastian Hengst
Ting-Yu Lin
Nathan Froyd