eTopLevel is reused in content process to indicates that the mouse leaves
the puppet widget rendering area, now we add a separated type, ePuppet, for it.
Differential Revision: https://phabricator.services.mozilla.com/D84748
The abstract observer base classes are moved to a separate header file
nsRefreshObservers.h and the includes are adjusted accordingly.
Some method implementations are moved to the corresponding implementation files
to avoid the need to include the nsRefreshDriver.h file in the header.
Differential Revision: https://phabricator.services.mozilla.com/D85764
nsPreContext::mDynamicToolbarHeight is representing the state of the dynamic
toolbar in transition or is being collapsed. So if we leave the value as it is,
we misrecognize the state, the visual viewport width/height are significantly
affected by the misrecognition, it returns 0 because in the collapsed or the
transition state, it returns the special value [1] which is never properly set
without calling nsPresContext::UpdateDynamicToolbarOffset.
This mismatching state doesn't much matter in the real sites since we don't
often change the max height of the dynamic toolbar but in automated tests it's
a big problem. In fact a test case which will be introduced in the next commit
will not work properly without this fix.
[1] https://searchfox.org/mozilla-central/rev/1b95a0179507a4dc7d4b0c94c2df420dc1a72885/dom/base/VisualViewport.cpp#78
Differential Revision: https://phabricator.services.mozilla.com/D83902
This is a straightforward conversion except that
`NS_SUBTREE_DIRTY(this)` can be written terser as `IsSubtreeDirty()`.
Differential Revision: https://phabricator.services.mozilla.com/D82811
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
While it makes sense to do this when the visual viewport offset changes, it
doesn't make as much sense when the visual viewport size changes. The size can
change whenever non-overlay scrollbars are added or removed to the root
scrollframe, which is an operation that seems like it shouldn't interfere with
scroll anchoring at all.
Differential Revision: https://phabricator.services.mozilla.com/D81071
After the above, I don't think this is needed anymore, because we
shouldn't be looking at the widget size from layout.
It also shouldn't cause more reflows on desktop at least, because of the
early out in ResizeReflowIgnoreOverride before calling
SimpleResizeReflow().
Differential Revision: https://phabricator.services.mozilla.com/D80731
We did not pass FLAG_HIGH_QUALITY_SCALING down to the document used to
rasterize the SVG to a surface, resulting in embedded raster images to
not use high quality downscaling.
Differential Revision: https://phabricator.services.mozilla.com/D56422
There's a lot of documents that get created (about:blank and friends) and this
makes it easier to figure out which MVM we actually care about.
Differential Revision: https://phabricator.services.mozilla.com/D80085
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
There's a lot of documents that get created (about:blank and friends) and this
makes it easier to figure out which MVM we actually care about.
Differential Revision: https://phabricator.services.mozilla.com/D80085
There's no need to put this in nsLayoutUtils since it's so closely bound
to presShell anyway. So we move it from being a static nsLayoutUtils function
that takes a PresShell pointer, to being a method on the PresShell itself.
Two functional changes here:
1. Don't run the MaybeReflowForInflationScreenSizeChange code unless the
visual viewport actually changes
2. Run the MaybeReflowForInflationScreenSizeChange if the visual viewport
is reset.
These functional changes can be logically thought of as "group the font-
inflation reflow stuff together with the other visual-viewport-triggered
reflow stuff".
Depends on D80040
Differential Revision: https://phabricator.services.mozilla.com/D80041
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
The existing comment in BrowserChild::RecvUpdateDimensions may have been
accurate at some point in the past, but I'm seeing cases where setting
the content viewer size itself triggers a reflow. Since the widget size
hasn't been updated yet, the reflow uses some stale values and produces
incorrect outcomes. This patch ensures both the content viewer and widget
get their sizes updated first, and only then do we do the reflow.
Differential Revision: https://phabricator.services.mozilla.com/D79885
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
For regular elements, whenever -moz-appearance is used, the CSS background is
ignored. Root elements were behaving specially, and the background color also
needed to be adjusted.
For example, for Windows 7, we have the following CSS rule;
```
:root {
background-color: transparent;
-moz-appearance: -moz-win-borderless-glass;
}
```
This change makes the root element more consistent with other elements, if non-glass
-moz-appearance values are used. For example, for platforms where `-moz-appearance: dialog`
has (partially) transparent rendering, the extra `background-color: transparent`
declaration is now no longer necessary.
This patch preserves the behavior for Windows 7 glass because there are several other
things that would need to be adjusted for the glass case (see bug 1601183 and bug 1599366).
Maybe we can just wait until we drop Windows 7 entirely, to clean this up.
This change does not let content documents opt out of forced opaqueness:
Root content documents still get an opaque background color from an existing
check further down in this method.
Differential Revision: https://phabricator.services.mozilla.com/D51459
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
It does not make sense to ask for layout coordinates relative to
a chrome document. If the chrome document has a zoomed (RCD)
descendant in the same process, this means we do not apply the
visual-to-layout transform when later entering the RCD.
Depends on D79588
Differential Revision: https://phabricator.services.mozilla.com/D79589
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
Allowing the MVM to control the reflow means that the requested reflow size
is ignored, and instead the existing CSS/layout viewport is used. This is
undesirable for calls to SizeToContent(), where the intent is to do a reflow
to figure out the smallest amount of space the content fits in.
In general though unless we are using mobile viewport sizing we shouldn't be
needing the MVM to drive reflows.
Differential Revision: https://phabricator.services.mozilla.com/D79225
