This should be equivalent because:
* Content viewer size and widget size should eventually be the same always
(modulo mid-resize, see bug 1645954).
* Only the root content document has a widget on android (the puppet widget).
* Only the root content document has a dynamic toolbar.
* We were only calling this on the root document, which has no parent pres
context (at least with e10s). Without e10s we could have a chrome
prescontext (not sure it that ends up being a parent in the pres context
chain), but we should never change the resolution of that one, so I think
aScaleContentViewerSize is just useless.
This avoids having two sources of truth by always checking the content viewer
size without subtracting the dynamic toolbar max size.
Differential Revision: https://phabricator.services.mozilla.com/D80723
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
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 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
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
And use the duplicated one at the places where we need the expanded size for
interactions with the dynamic toolbar on the compositor. The new function will
be modified in the next commit.
Note that the only one remaining call site of ExpandHeightForViewportUnits is
for window.inner{Width,Height}. For window.inner{Width,Height} we don't yet
return the layout viewport (which might be expanded by the minimum-scale), it's
going to be fixed in bug 1598487 [1], but it's not ready to fix because there
also need fixes in comm-central (see dependencies in the bug). So for now, we
should keep the current behavior for window.inner{Width,Height}.
Also note that it's not yet clear whether we will eventually replace the last
call site of ExpandHeightForViewportUnits with ExpandHeightForDynamicToolbar
since the value corresponding to the dynamic toolbar might _NOT_ be affected by
the minimum-scale in some cases. See bug 1641166 for details.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1598487
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1641166
Differential Revision: https://phabricator.services.mozilla.com/D78440
This patch is a fairly mechanical conversion. The old `nullptr` gets converted
to ScrollOrigin::NotSpecified, and all the other possible values get corresponding
values in the new ScrollOrigin enum. A few switch statements are introduced to
clean up big if statements, but other than that, additional cleanups will happen
in later patches.
Differential Revision: https://phabricator.services.mozilla.com/D78438
The viewport units size doesn't match the aspect ratio of the screen size in
some cases.
For example, in the case of the reftest in this commit, the meta viewport is
"width=1600, height=device-height" and the screen size during reftest is
"800x1000". Thus the viewport units size will be "1600x1000". In such cases
with the old way ExpandHeightForViewportUnits shrinks the given size
"1600x1800" to "1600x1000" with 100px dynamic toolbar max height (and the
MOZ_ASSERT in the function happens on debug builds).
Differential Revision: https://phabricator.services.mozilla.com/D77176
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This allows headers which nsLayoutUtils.h includes to use these types without
creating a circular dependency.
As part of this change, the types are also moved into namespace mozilla.
Differential Revision: https://phabricator.services.mozilla.com/D71704
This is the "core" change of the patch series, which causes most
existing layout codepaths to correctly factor in the visual to
layout transform (or its inverse), as long as the callers correctly
propagate it in the correct ViewportType.
Differential Revision: https://phabricator.services.mozilla.com/D68920
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This allows headers which nsLayoutUtils.h includes to use these types without
creating a circular dependency.
As part of this change, the types are also moved into namespace mozilla.
Differential Revision: https://phabricator.services.mozilla.com/D71704
This is the "core" change of the patch series, which causes most
existing layout codepaths to correctly factor in the visual to
layout transform (or its inverse), as long as the callers correctly
propagate it in the correct ViewportType.
Differential Revision: https://phabricator.services.mozilla.com/D68920
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This allows us to have a single const_cast inside GetFramesForArea, and
avoid several callers of these functions (which, as of bug 1556556,
get a const nsIFrame* from RelativeTo inputs) having to const_cast.
Differential Revision: https://phabricator.services.mozilla.com/D70068
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
