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
With this change the displayport moves by screen (or a scroll-frame) up to a quarter of the displayport size instead of every 128 pixels when WebRender is enabled.
Also separate the alignment of the position and size to allow moving the displayport in much larger increments without increasing the displayport size which regresses tscrollx and generally increases webrender's CPU load.
Differential Revision: https://phabricator.services.mozilla.com/D77870
Asking for layout coordinates relative to the RCD viewport frame
is a special case because the RCD viewport frame is outside the
zoom boundary, and so should technically always use visual
coordinates.
Nonetheless, we need to use layout coordinates relative to the
RCD viewport frame in several places, as we don't have a frame
that's inside the zoom boundary and sized to the initial
containing block (bug 1641279 may introduce such a frame in the
future).
This means GetEventCoordinatesRelativeTo needs special handling
to apply the visual-to-layout transform when converting from
visual coordinates relative to the root document's viewport
frame, to layout coordinates relative to the RCD viewport frame.
If the RCD is the root document, we take the fast-path which
handled this with an explicit check, but if the RCD is not the
root document, we take the slow-path which does not handle this.
This patch refactors GetECRT so it always checks for this
special case at the end.
Depends on D79589
Differential Revision: https://phabricator.services.mozilla.com/D79590
Also separate the alignment of the position and size to allow moving the displayport in much larger increments without increasing the displayport size which regresses tscrollx and generally increases webrender's CPU load.
Differential Revision: https://phabricator.services.mozilla.com/D77870
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 uses "None" instead of "NotSpecified" as the value for
mLastSmoothScrollOrigin when there is no smooth scroll in progress.
Depends on D78439
Differential Revision: https://phabricator.services.mozilla.com/D78469
This adds a new scroll origin, None, which is used as the initial value for
mLastScrollOrigin. Unlike Other, this scroll origin can be clobbered by any
other scroll origin, including notably Relative. This means that on a
brand-new scrollframe, if the first scroll call comes in with an origin of
Relative, it will be preserved as a relative scroll instead of getting
converted to a non-relative scroll.
This in turn fixes a latent bug in the code that was exposed by the
test_relative_update.html APZ mochitest when run with apz.allow_zooming=true.
Note also that we should never be passing eNone to functions like ScrollToImpl;
for those scenarios we continue using Unknown if we don't have a more specific
scroll origin to use. In other words, None is a sort of sentinel value to be
used for class fields, and is not to be used for actual scrollto-type calls.
Differential Revision: https://phabricator.services.mozilla.com/D78439
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
If we called PaintFrame for drawWindow or something other than painting to the widget the visual scroll update won't make it to the compositor, so don't clear it.
This doesn't fix anything specifically, just noticed it while reading code.
Differential Revision: https://phabricator.services.mozilla.com/D76781
This makes it more obvious that we are using the same scrollDelta for adjusting
the displayport as we are for populating the callback transform. Instead of
computing the same value inside a helper, we just provide the helper with the
already-computed delta that is used for the callback transform too.
Differential Revision: https://phabricator.services.mozilla.com/D76297
- Fixed wrong 'line' comparison
- Fixed clang-tidy warning
- Addressed the final review comments.
- Fixed the build failures happening in DEBUG mode. Had to revert the range based for loop usage at one place.
Differential Revision: https://phabricator.services.mozilla.com/D75673
This patch is generated by using my editor's rename functionality.
In the next patch, `nsIFrame::` prefix is going to be removed manually
from all the ChildLists() calls.
Differential Revision: https://phabricator.services.mozilla.com/D75893
- Fixed clang-tidy warning
- Addressed the final review comments.
- Fixed the build failures happening in DEBUG mode. Had to revert the range based for loop usage at one place.
Differential Revision: https://phabricator.services.mozilla.com/D75673
The original change causes a large tscrollx linux64-shippable-qr regression, we'll have to revisit this after we better understand the regression.
Differential Revision: https://phabricator.services.mozilla.com/D75045
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
The idea here is:
* The incoming point comes from WidgetEvent::mRefPoint which is in
visual coordinates.
* Depending on the value of the target RelativeTo parameter, we
may need to convert this to layout coordinates.
* In the fast-path, we do a direct check on the viewport type
and apply the visual-to-layout transform if appropriate.
* In the slow path, we rely on TransformRootPointToFrame() (which
calls GetTransformToAncestor()) to include the visual-to-layout
transform if appropriate, by correctly passing in
ViewportType::Visual as the starting point.
* To make sure we get into TransformRootPointToFrame(), we
set transformFound if we'll be crossing a zoomed content root.
Differential Revision: https://phabricator.services.mozilla.com/D68921
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
Prior to this bug, it was necessary to handle non-e10s specially, because the
resolution was being unapplied at the process boundary, and in non-e10s there
was no process boundary.
The remaining patches in this bug move the resolution unapplication away from
the process boundary in all cases, making special handling for non-e10s
unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D68273
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
The idea here is:
* The incoming point comes from WidgetEvent::mRefPoint which is in
visual coordinates.
* Depending on the value of the target RelativeTo parameter, we
may need to convert this to layout coordinates.
* In the fast-path, we do a direct check on the viewport type
and apply the visual-to-layout transform if appropriate.
* In the slow path, we rely on TransformRootPointToFrame() (which
calls GetTransformToAncestor()) to include the visual-to-layout
transform if appropriate, by correctly passing in
ViewportType::Visual as the starting point.
* To make sure we get into TransformRootPointToFrame(), we
set transformFound if we'll be crossing a zoomed content root.
Differential Revision: https://phabricator.services.mozilla.com/D68921
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
