This was originally removed due to bug 1341513. Unfortunately this method can
still have occasional value in places which call use a macro which declares a
`nsLiteral[C]String`. This changes some of those callers over & re-adds the
`.get()`.
Differential Revision: https://phabricator.services.mozilla.com/D286157
After the previous patches, nsViewManager is basically a backpointer to
its pres shell.
Remove it and just make PresShell manage the root view directly. After
this is done, we can decide what to do about nsView (which is itself
little more than a widget listener that forwards to pres shell right
now).
This technically starts listening to mParentWidget slightly later (on
pres shell creation), but I think that's ok.
Differential Revision: https://phabricator.services.mozilla.com/D272890
There's a race condition where the keyboard height change notification
has arrived but nsDocumentViewer size change hasn't yet arrived.
MobileViewportManager::mPendingKeyboardHeight is introduced to fix the race.
Differential Revision: https://phabricator.services.mozilla.com/D234262
There's a race condition where the keyboard height change notification
has arrived but nsDocumentViewer size change hasn't yet arrived.
MobileViewportManager::mPendingKeyboardHeight is introduced to fix the race.
Differential Revision: https://phabricator.services.mozilla.com/D234262
On mobile environments, specifically web contents without meta viewport tags get
rendered on 980px width device (i.e. desktop mode), thus using the document
viewer size directly for the pres context's visible area would result a resize event.
Using MobileViewportManager avoids the resize event.
Differential Revision: https://phabricator.services.mozilla.com/D220976
The log statement in ComputeIntrinsicScale() was quite noisy because one
of its callers was called on every paint. The patch moves it to the
non-noisy call sites, and details whether the intrinsic scale is being
computed based on the viewport size or content size.
Also add a couple of new log statements.
Differential Revision: https://phabricator.services.mozilla.com/D216902
So that even if the chrome window gets resized by the software keyboard, the
contents can be laid out as if there's no software keyboard for overlays-content
and resizes-visual modes.
Also use the exapanded size (we call it "layout display size") for all call sites of
MobileViewportManager::DisplaySize().
Differential Revision: https://phabricator.services.mozilla.com/D204167
So that even if the chrome window gets resized by the software keyboard, the
contents can be laid out as if there's no software keyboard for overlays-content
and resizes-visual modes.
Also use the exapanded size (we call it "layout display size") for all call sites of
MobileViewportManager::DisplaySize().
Differential Revision: https://phabricator.services.mozilla.com/D204167
When the dynamic toolbar is collapsed, the viewport frame size for
`position: fixed` elements is
`MobileViewportManager::mVisualViewportSizeUpdatedByDynamicToolbar`.
But the variable wasn't updated when the visual viewport size is changed by the
software keyboard.
Differential Revision: https://phabricator.services.mozilla.com/D198112
Before this patch, PresShell.cpp tries to reuse a LazyLogModule that's defined
in MobileViewportManager.cpp, which isn't actually declared in any header. This
prevents the build from linking, unless we're lucky enough to have these two
source files concatenated together via our unified build.
This patch promotes this LazyLogModule to be an actual static member-var on the
MobileViewportManager class, so that it can be exported and used externally in
a more structured way. This makes it consistent with the very-similar
"PresShell::gLog" member-variable.
Differential Revision: https://phabricator.services.mozilla.com/D125600
In the case of reflowing caused by full zoom changes, the mDisplaySize isn't
changed, whereas mMobileViewportSize should be changed.
Differential Revision: https://phabricator.services.mozilla.com/D120190
In the case of reflowing caused by full zoom changes, the mDisplaySize isn't
changed, whereas mMobileViewportSize should be changed.
Differential Revision: https://phabricator.services.mozilla.com/D120190
In the case of reflowing caused by full zoom changes, the mDisplaySize isn't
changed, whereas mMobileViewportSize should be changed.
Differential Revision: https://phabricator.services.mozilla.com/D120190
This seems to match Chrome, and makes our fullscreen implementation more
consistent between desktop and mobile.
Do you know how to best test this? This repros in RDM, but all
fullscreen tests seem disabled on Android...
Differential Revision: https://phabricator.services.mozilla.com/D107365
Also add AsyncPanZoomController::CanScrollDownwardsWithDynamicToolbar to tell
whether the root APZC is scrollable or there is room covered by the dynamic
toolbar so that we can tell GeckoView to move the dynamic toolbar in such cases.
Differential Revision: https://phabricator.services.mozilla.com/D93914
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
When meta-viewport support is enabled, the call to UpdateResolutionForFirstPaint
from RefreshViewportSize is followed by a call to ShrinkToDispalySizeIfNeeded,
which calls UpdateResolutionForContentSizeChange and uses the scrollable rect
size for the intrinsic scale computation. So the intrinsic scale computation
in UpdateResolutionForFirstPaint causes a transient state where the resolution
and visual viewport size is wrong. It is corrected immediately after, but
changing the visual viewport size like that ends up marking frames dirty for
reflow. Avoiding the transient state avoids those reflows, which is a nice
optimization.
Differential Revision: https://phabricator.services.mozilla.com/D80996
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
This fixes a number of scroll-anchoring WPT tests that otherwise fail with the
final patch in this patchset. This patch also fixes a pre-existing failure on
Android, so we remove the corresponding failure annotation here. The guard
being added already exists on some of the codepaths leading to this function,
and is used to short-circuit other bits of code. However, there are still some
codepaths that end up in this function with a zero display size, and it's better
to leave the visual viewport unset in the presShell than to set it to a zero
size.
Depends on D80086
Differential Revision: https://phabricator.services.mozilla.com/D80087
This fixes a number of scroll-anchoring WPT tests that otherwise fail with the
final patch in this patchset. This patch also fixes a pre-existing failure on
Android, so we remove the corresponding failure annotation here. The guard
being added already exists on some of the codepaths leading to this function,
and is used to short-circuit other bits of code. However, there are still some
codepaths that end up in this function with a zero display size, and it's better
to leave the visual viewport unset in the presShell than to set it to a zero
size.
Depends on D80086
Differential Revision: https://phabricator.services.mozilla.com/D80087
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
Nika Layzell