This introduces a linear interpolation when computing the wheel animation
durations, based on the migration percentage of the user. Initially the
migration percentage defaults to 100 (fully migrated) for new users and for
existing users who have customized these prefs. The migration percentage
defaults to zero for existing users without customizations, so they will
still get the old default values of min=200,max=400. Over time we can adjust
the migration pref clamping to move that percentage up and migrate those
users to get the new values.
Differential Revision: https://phabricator.services.mozilla.com/D88163
Now that main thread scroll updates preserve the relative scroll offset
in APZ, this hacky fix is no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D87687
AFAICT the spec says that these layout scrollbars that take up no layout space that scroll the visual viewport do affect the size of the visual viewport. (Double check this)
Most other users don't care about the size of these special scrollbars.
I left nsIDOMWindowUtils::getScrollbarSize unchanged (NB different from nsIDOMWindowUtils::getScrollbarSizes which is modified by this patch) because I'm less sure. I will file a followup about it.
Differential Revision: https://phabricator.services.mozilla.com/D85708
The existing calculation will make them overlap. The AdjustOverlappingScrollbars code was written with overlay scrollbars in mind but it looks like it will work just fine for this case.
Differential Revision: https://phabricator.services.mozilla.com/D85707
Otherwise the calculation above would lead to an empty rect for the scroll corner.
The scrollbar rects as computed now still overlap each other and the scroll corner, the next patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D85706
There is no dependency in this code as far as I can tell.
The next patch needs the scrollbar rects for the scroll corner calculation.
Differential Revision: https://phabricator.services.mozilla.com/D85705
Layout scrollbars that were only created for the visual viewport had no space reserved for them, so we need to shift them back in like overlay scrollbars. Otherwise they sit just outside of the scroll port and are not visible.
Differential Revision: https://phabricator.services.mozilla.com/D85704
For the former we are still allowed to show scrollbars if we need to scroll the visual viewport inside the layout viewport (as long as they take up no layout space). For the latter we still do not want to show scrollbars.
The ShowScrollbar enum is now only from layouts perspective and doesn't take into account anything about the visual viewport.
Differential Revision: https://phabricator.services.mozilla.com/D85700
This will actually regress behaviour when overflow is auto and pinch zooming creates scrollable overflow (scrolling the visual viewport inside the layout viewport). We will fix that in later patches.
The reason that this is necessary is that the code as-is is incorrect if we have layout scrollbars (scrollbars that take up space). If we have layout scrollbars and we pinch zoom and we go from not needing a scrollbar to needing a scrollbar then that scrollbar cannot take up layout space (even though it is a layout scrollbar). The scrollbar cannot change the size of the layout viewport (it does, however, change the size of the visual viewport).
In later patches we fix this situation as well as the situation with an overflow hidden document (which also needs to create scrollbars when pinch zoomed).
Differential Revision: https://phabricator.services.mozilla.com/D85699
This restricts the workaround to mobile a bit better, since the
GetIsViewportOverridden() check returns true on desktop as of bug 1644271.
Differential Revision: https://phabricator.services.mozilla.com/D86414
AFAICT the spec says that these layout scrollbars that take up no layout space that scroll the visual viewport do affect the size of the visual viewport. (Double check this)
Most other users don't care about the size of these special scrollbars.
I left nsIDOMWindowUtils::getScrollbarSize unchanged (NB different from nsIDOMWindowUtils::getScrollbarSizes which is modified by this patch) because I'm less sure. I will file a followup about it.
Differential Revision: https://phabricator.services.mozilla.com/D85708
The existing calculation will make them overlap. The AdjustOverlappingScrollbars code was written with overlay scrollbars in mind but it looks like it will work just fine for this case.
Differential Revision: https://phabricator.services.mozilla.com/D85707
Otherwise the calculation above would lead to an empty rect for the scroll corner.
The scrollbar rects as computed now still overlap each other and the scroll corner, the next patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D85706
There is no dependency in this code as far as I can tell.
The next patch needs the scrollbar rects for the scroll corner calculation.
Differential Revision: https://phabricator.services.mozilla.com/D85705
Layout scrollbars that were only created for the visual viewport had no space reserved for them, so we need to shift them back in like overlay scrollbars. Otherwise they sit just outside of the scroll port and are not visible.
Depends on D85703
Differential Revision: https://phabricator.services.mozilla.com/D86332
For the former we are still allowed to show scrollbars if we need to scroll the visual viewport inside the layout viewport (as long as they take up no layout space). For the latter we still do not want to show scrollbars.
The ShowScrollbar enum is now only from layouts perspective and doesn't take into account anything about the visual viewport.
Differential Revision: https://phabricator.services.mozilla.com/D85700
This will actually regress behaviour when overflow is auto and pinch zooming creates scrollable overflow (scrolling the visual viewport inside the layout viewport). We will fix that in later patches.
The reason that this is necessary is that the code as-is is incorrect if we have layout scrollbars (scrollbars that take up space). If we have layout scrollbars and we pinch zoom and we go from not needing a scrollbar to needing a scrollbar then that scrollbar cannot take up layout space (even though it is a layout scrollbar). The scrollbar cannot change the size of the layout viewport (it does, however, change the size of the visual viewport).
In later patches we fix this situation as well as the situation with an overflow hidden document (which also needs to create scrollbars when pinch zoomed).
Differential Revision: https://phabricator.services.mozilla.com/D85699
UpdateScrollbarPosition and ReflowFinished both use the scroll range for this. It usually doesn't matter, but the next patch will make it important.
Differential Revision: https://phabricator.services.mozilla.com/D85983
This patch basically attempts to make clicking in the scrollbar track outside of the scrollthumb "work". Clicking in the scrollbar track usually does a page scroll via nsSliderFrame::PageScroll. This eventually ends up in ScrollFrameHelper::ScrollBy where we turn the request from a relative one ("scroll by a page") into an absolute one ("scroll to this position").
This page scroll is typically a smooth scroll and is currently done on the main thread/layout side. Once we start scrolling the visual viewport offset with the scrollbars we can no longer do this purely on the layout side, we at least need the help of the compositor side. I think the simplest way to do this is to hand the scroll request off to the compositor and have it handle the whole thing.
Now we need to consider the following situation: user clicks scrollbar track to page scroll, smooth scroll gets partway complete on the compositor, user clicks again on scrollbar track for a further page scroll. The main thread can't send an absolute scroll offset update request to the compositor at this point because it has outdated information (it needs a 'starting position' to add the page scroll offset amount) so it'll end up scrolling to the wrong place. It has to send a relative scroll offset update.
We already have a mechanism to send relative scroll offset updates. It is implemented by sending a base scroll offset and the desired scroll offset, and then on the compositor send the difference between those two is computed and then added to the scroll offset.
This patch creates a new mechanism (so called "pure relative") that just sends a relative offset update without any absolute scroll positions. The reason I did this is because the existing relative scroll offset update mechanism is not aware of visual viewport offsets, but rather only layout scroll position. For example, here
https://searchfox.org/mozilla-central/rev/8d55e18875b89cdf2a22a7cba60dc40999c18356/layout/generic/nsGfxScrollFrame.h#446
the value we use for the base scroll offset (mApzScrollPos) is set to the layout scroll position. It may be entirely reasonable to make this existing mechanism vv offset aware, but I wanted to implement something to get it working with a smaller chance of regressions to things that already exist and work. Ideally these two mechanims would be merged.
Differential Revision: https://phabricator.services.mozilla.com/D82688
If there are mix-blend-mode items inside the async zoom container, the
BlendContainer can end up outside the async zoom container, at the top-level
stacking context. But this causes the blend mode to fail with WebRender.
Instead, if we are creating an async zoom container, we check to see if there
was a mix-blend-mode inside it, and create the blend container just inside
the async zoom container.
Differential Revision: https://phabricator.services.mozilla.com/D82186
Also: adjust include paths to be consistent for usages of various SVG headers,
and remove unused SVG includes (mostly for "utils" classes),
and drop stray "ns" from already-renamed SVG classes in various code comments.
Differential Revision: https://phabricator.services.mozilla.com/D83140
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
If the root scrollframe has the zoomable flag set, it automatically returns
true from WantAsyncScroll which makes it the "primary" scrollframe, and
automatically gets a displayport. However, this can be undesirable in cases
where the root scrollframe is not actually scrollable (i.e. document content
doesn't overflow) because we don't actually need that displayport on the root
scrollframe and instead want it on a scrollframe that is actually scrollable.
This patch removes the behaviour of WantAsyncScroll returning true for such
scrollframes, but maintains the layerization changes needed to support zooming.
This reduces the set of differences between running with apz.allow_zooming on
and off, which in turn eliminates a bunch of test failures when that pref is
enabled.
Depends on D82777
Differential Revision: https://phabricator.services.mozilla.com/D82778
Instead of checking for the visual viewport *size* being set, we check for
the *offset* being set. This makes more sense becuase we're going to be
reading the offset, not the size.
Depends on D81740
Differential Revision: https://phabricator.services.mozilla.com/D81741
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 positioning overlay scrollbars, the code was previously taking the
visual viewport size and scaling it back up to the composition size using
the resolution. This works because overlay scrollbars don't take up any
space, and so the visual viewport size is exactly equal to the composition
size divided by the resolution. However, it's simpler to just use the
composition size because we can get that easily enough. And this fixes the
scrollbar positioning on the very first reflow, before the visual viewport
has been set on the presShell.
Eventually this might make it easier to do this for non-overlay scrollbars
as well, since those do take up layout space, and can't be positioned using
the "VV size multiplied by resolution" quantity, as that doesn't exactly
equal the composition size.
Differential Revision: https://phabricator.services.mozilla.com/D81277
The TryLayout code uses the composition size to figure out if the
scrollbar is needed or not. It computes something similar to the visual
viewport size (but assuming no scrollbars are taking up space) to do this.
There's no reason this code should be depending on whether or not the
visual viewport size is set in the presShell, so we can just remove the
condition. That way even on the very first reflow, when the visual viewport
will definitely not be set, we can correctly determine if the scrollbars
need to be laid out or not.
Differential Revision: https://phabricator.services.mozilla.com/D81276
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
mLastPos is supposed to be updated by querying the visual viewport offset from
the presShell. However because of the way the visual viewport offset is updated,
this doesn't return a nonzero value until after APZ sends back a repaint request.
So this patch modifies the query to also check if there's any pending visual
viewport offset update being sent from the main thread, and use that. It also
modifies the scroll restoration code to request a properly clamped visual
scroll offset, so that the value stored as "pending" is not just the unclamped
restore destination.
Depends on D80038
Differential Revision: https://phabricator.services.mozilla.com/D80039
With containerless scrolling we generally always want this clip on the layer,
since there is no container. However on Android apparently we don't want this,
because it seems to break the setVerticalClipping API used by the dynamic
toolbar.
Differential Revision: https://phabricator.services.mozilla.com/D80054
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
The modifications are all straightforward conversion except the one in
nsMathMLContainerFrame, where it is simplified by calling the equivalent
BuildDisplayListForInline() helper.
Differential Revision: https://phabricator.services.mozilla.com/D78166
In favor of the NativeAnonymous versions which they forward to.
Done automatically with:
rg -l 'IsInAnonymousSubtree' | xargs sed -i 's/IsInAnonymousSubtree/IsInNativeAnonymousSubtree/g'
And removing the function definitions afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D76681
nsChildView.mm already does this via systemMetricsChanged.
There used to be a bug in which pref changes to the ui.* prefs didn't
trigger ThemeChanged, but it was fixed a while ago.
Differential Revision: https://phabricator.services.mozilla.com/D76530
We want to use a page scroll amount based on the visual viewport size.
The extra complications we have for not scrolling too far if there are fixed/sticky position things are quite hard to do properly with a visual viewport (I tried). I think there is far less user expectation of it working if a visual viewport is set. If we get complaints we can look into it.
Differential Revision: https://phabricator.services.mozilla.com/D76091
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
Previously, we were only performing part of this transform
(scaling by the resolution) and not the other part
(translating by the offset between the two viewports).
Differential Revision: https://phabricator.services.mozilla.com/D75739
Given there's content depending on it. This brings back the check from
before the regression.
I had to tweak percent-height-overflowing-image-1.html so that it
doesn't hit scrollbar size limits on GTK (which are a bit ridiculous
IMHO, but oh well).
Differential Revision: https://phabricator.services.mozilla.com/D75171
The user-observed behaviour should be unchanged, but for testing purposes
this produces more consistent results between WR and non-WR. It also seems
conceptually more correct so I think it's worth doing.
Depends on D74789
Differential Revision: https://phabricator.services.mozilla.com/D74790
That is, so that the select dropdown button always take the size of a
native scrollbar rather than a potentially custom scrollbar.
Differential Revision: https://phabricator.services.mozilla.com/D73261
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 "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 is used by platforms with overlay scrollbars, only in order to
reserve enough space for the chevron of the `<select>` element.
So our general min-widget-size, which is the same as for scrollbars
works.
Differential Revision: https://phabricator.services.mozilla.com/D71825
The displayport clip that is applied to sticky items from the enclosing
scrollframe can cause sticky items to checkerboard even when they might
reasonably be left visible. This is because the displayport clip moves as
the enclosing scrollframe is scrolled, but sticky items may remain fixed
during such scrolling. The displayport clip can therefore clip out sticky
items even if they are "stuck" and should be user-visible.
This patch sets a flag to identify when a sticky item is being clipped by
the displayport clip, and ensures that it doesn't actually get clipped. In
the case where other clips are being applied to the sticky item, we leave the
clips unaffected. This allows for other enclosing elements to clip the sticky
item as before.
Differential Revision: https://phabricator.services.mozilla.com/D68582
--HG--
extra : moz-landing-system : lando
Converts layout.framevisibility.numscrollportwidths and layout.framevisibility.numscrollportheights to static prefs.
Differential Revision: https://phabricator.services.mozilla.com/D69615
--HG--
extra : moz-landing-system : lando
This patch also tries to remove the event target entirely if it would
default to the main thread on a null event target.
Depends on D67634
Differential Revision: https://phabricator.services.mozilla.com/D67635
--HG--
extra : moz-landing-system : lando
If we can get the root frame's displayport, then we should use that
rect instead of the root composition bounds when clipping the scrollframe's
displayport. That way if APZ is disabled on the scrollframe, but the root
frame scrolls to bring a part of it into view, it will be fully painted and
not perma-checkerboard-y.
Note that this patch is the main fix, but leaves a bunch of comments/variables
with bad names; the next patch cleans that up.
Differential Revision: https://phabricator.services.mozilla.com/D66421
--HG--
extra : moz-landing-system : lando
There were some callers in nsRangeFrame that were already not-null-checking.
All platforms have a native theme and should we add new ones they could use
nsBasicNativeTheme.
Differential Revision: https://phabricator.services.mozilla.com/D65169
--HG--
extra : moz-landing-system : lando
Reuse the AddXULMinSize logic which already deals with all the widget stuff,
non-themed scrollbars, etc.
Remove some useless margin declarations and such in GeckoView scrollbars code
now that AddXULMinSize does look at the min-width/height properties.
Differential Revision: https://phabricator.services.mozilla.com/D65129
--HG--
extra : moz-landing-system : lando
Reuse the AddXULMinSize logic which already deals with all the widget stuff,
non-themed scrollbars, etc.
Remove some useless margin declarations and such in GeckoView scrollbars code
now that AddXULMinSize does look at the min-width/height properties.
Differential Revision: https://phabricator.services.mozilla.com/D65129
--HG--
extra : moz-landing-system : lando
In some cases (such as the case from this bug) the display list contains a
"hoisted" scrollinfo display item, which indicates the presence of a scroller
inside an inactive layer subtree (e.g. a div with certain kinds of filters).
The scrollinfo display item is "hoisted" outside the display list subtree so
that it doesn't get flattened away inside the inactive subtree. That display
item then causes the compositor hit-test regions to updated appropriately so
that APZ knows about the scrollframe inside the flattened content. This in turn
allows APZ to request main-thread scrolling for that scrollframe when input
events are directed to it.
With the WebRender codepath, the information represented by the hoisted
scrollinfo display item was being lost instead of being propagated to the
compositor. This was because the mechanism used for information propagation is
different (WebRender commands vs layers EventRegions). This patch ensures that
the scrollinfo display items also generate appropriate WebRender commands so
that the information is not lost, and WR knows about the scrollframe inside
the flattened content.
The patch includes:
- A code movement in nsGfxScrolllFrame.cpp so that necessary information can
be provided to the nsDisplayScrollInfoLayer constructor
- Updates to nsDisplayScrollInfoLayer members to store the necessary information
- Addition of nsDisplayScrollInfoLayer::CreateWebRenderCommands which propagates
the information to the WR display list
- A test to exercise the changes.
Differential Revision: https://phabricator.services.mozilla.com/D63869
--HG--
extra : moz-landing-system : lando
To avoid computing transform bounds over and over. It is generally just better.
Replace the various "overridebounds" thingies by using the "fallback" of the
transform-reference-box code which we need anyway.
Differential Revision: https://phabricator.services.mozilla.com/D61890
--HG--
extra : moz-landing-system : lando
This patch changes the zoom behavior to always be routed through the frontend
Zoom Actor. In the existing code, the ZoomChangeUsingMouseWheel event is sent
as an after-the-fact notification of the zoom being modified directly. This
part of the patch supplements the existing event with 2 new events that
trigger the frontend to do the +/- 10% math in ChangeFullZoom and
ChangeTextZoom. The next part of the patch supplies that logic in the frontend
Zoom Actor.
This also changes the handling of events from the zoom in/out keys. Before,
those keys would only change full zoom levels. Now, they will respect the
full zoom vs text zoom toggle.
Differential Revision: https://phabricator.services.mozilla.com/D59259
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
We also need to adjust the scroll range we use. We do this by adding GetScrollRangeForUserInputEvents which just uses the range that GetAvailableScrollingDirectionsForUserInputEvents computed.
This should give two improvements:
1) CanScrollOn will not report that the user can scroll in an overflow hidden direction.
2) CanScrollOn will report that the user can scroll in an overflow hidden direction if the document is pinch zoomed in so that the user can scroll around the layout viewport.
Differential Revision: https://phabricator.services.mozilla.com/D56301
--HG--
extra : moz-landing-system : lando
This is similar to GetAvailableScrollingDirections but also takes into account any resolution.
Differential Revision: https://phabricator.services.mozilla.com/D57610
--HG--
extra : moz-landing-system : lando
Previously we were just checking overflow hidden here, which is not enough because we can scroll overflow hidden if we are zoomed in.
Differential Revision: https://phabricator.services.mozilla.com/D55918
--HG--
extra : moz-landing-system : lando
