This is needed because we don't want to create useless APZ scroll info
for view transitions (D248043), but that relies on these scrollframes
not being active.
Note that contents inside a view transition capture can't scroll.
Differential Revision: https://phabricator.services.mozilla.com/D248041
We should handle the root only in ScrollContainerFrame. We don't hit
this code-path more often because the root primary frame is usually not
a stacking context.
Differential Revision: https://phabricator.services.mozilla.com/D247590
Since last time we tried this:
* A lot of internal usage has gone away.
* They have been successfully been unshipped from content and
extensions.
So we should try this again.
Differential Revision: https://phabricator.services.mozilla.com/D5271
In the case of `overflow:hidden` scroll container, async scroll
operations are handled on the main-thread. And the scroll snap target ids
are also maintained on the main-thread either by mAsyncSmoothMSDScroll
or mAsyncScroll. But when re-using an existing mAsyncSmoothMSDScroll
instance (or mAsyncScroll), the first scroll snap target ids had persisted
in the instance, that resulted unexpected re-snapping.
Differential Revision: https://phabricator.services.mozilla.com/D238731
Though there's no problem even if we clear mSnapTargets in
ScrollContainerFrame::GetSnapPointForResnap, the main purpose of this change
is to avoid multiple call sites of ScrollSnapUtils::GetSnapPointForResnap
so that in the next change we only need to tweak the single call site.
Differential Revision: https://phabricator.services.mozilla.com/D239685
It's possible to unregister the timelines in Tick() if the
content-visibility changed. I'd like to avoid this to make things
simpler. Therefore, we add an extra flag and set it if we would like to
unregister this timeline while scheduling, and then we remove these
timelines after scheduling.
Differential Revision: https://phabricator.services.mozilla.com/D236642
The scroll target id is only used when we are actually painting to the window.
This avoids the significant time taken for IsScrollingActive and FindOrCreateIDFor during event handling display list builds.
Differential Revision: https://phabricator.services.mozilla.com/D230479
Just like what we do for EffectSet. Also, we will update
ElementAnimationData later, so for now only change the APIs of
AnimationCollection and TimelineCollection (and their callers).
Differential Revision: https://phabricator.services.mozilla.com/D228227
Basically, we'd like to separate the originating element and its pseudo
element request in Animation code (for better compatibility with Web
Animations APIs and other pseudo types), and store the animations and
keyframe effects in the origninating element as well.
In this patch, we reuse `Element::GetPseudoElement()`, and update the
function signatures in EffectCompositor and RestyleManager.
All the following patches will replace more places with
`PseudoStyleRequest`.
Differential Revision: https://phabricator.services.mozilla.com/D228223
This means that when users scroll to the inline-end of a scroller, they will
see that the inline-end padding of that scroller is added in.
This is achieved by unioning an additional rect into the scrollable element's
overflow area (Which is an accumulation of the recursive overflow-area
contributions from its subtree).
This additional rect is calculated as follows:
- In-flow children and float's margin boxes are unioned (including zero-size boxes)
- The unioned rect is then inflated by the scrollable element's padding
Note: The bounds of zero-area in-flow-child rects are included in this rect,
in both block- and inline- directions. This is a change in behavior; Divs of
huge inline size and zero block size used to not affect the scrollable overflow,
where divs with huge block size and zero inline size did, as a side effect of now
removed `nsBlockFrame::ConsiderBlockEndEdgeOfChildren`.
Note on WPT change sizing-orthog-(vlr|vrl)-in-htb-(008|020)-ref.xht - the padding existed
to force empty space below `p#sentence-after`. However, this only applies to previous
Firefox. Any combination of browser + default font (+ its default size) causing a scroll
would cause the test to fail as false positive (According to wpt.fyi, this is what happens
with sizing-orthog-(vlr|vrl)-008.xht tests). This change brings Firefox's scroll behaviour
inline with other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D151310
This is just a band-aid to avoid the undefined behavior of std::clamp;
our CSSMinMax handles the case in a predictable way.
The real issue here must be that the frame has reported a "negative"
block-size, presumably due to integer overflow during nscoord arithmetic.
If we get a pernosco trace of the assertion, perhaps we can identify the
source of the overflow and correct/clamp it earlier to avoid this.
Differential Revision: https://phabricator.services.mozilla.com/D228595
This means that when users scroll to the inline-end of a scroller, they will
see that the inline-end padding of that scroller is added in.
This is achieved by unioning an additional rect into the scrollable element's
overflow area (Which is an accumulation of the recursive overflow-area
contributions from its subtree).
This additional rect is calculated as follows:
- In-flow children and float's margin boxes are unioned (including zero-size boxes)
- The unioned rect is then inflated by the scrollable element's padding
Note: The bounds of zero-area in-flow-child rects are included in this rect,
in both block- and inline- directions. This is a change in behavior; Divs of
huge inline size and zero block size used to not affect the scrollable overflow,
where divs with huge block size and zero inline size did, as a side effect of now
removed `nsBlockFrame::ConsiderBlockEndEdgeOfChildren`.
Note on WPT change sizing-orthog-(vlr|vrl)-in-htb-(008|020)-ref.xht - the padding existed
to force empty space below `p#sentence-after`. However, this only applies to previous
Firefox. Any combination of browser + default font (+ its default size) causing a scroll
would cause the test to fail as false positive (According to wpt.fyi, this is what happens
with sizing-orthog-(vlr|vrl)-008.xht tests). This change brings Firefox's scroll behaviour
inline with other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D151310
On mobile environments, the `minimum-scale` size, which allows users to zoom
out to scales less than 1.0, should include the ICB's overflow, even when
`overflow-x:hidden` is specified on the root element.
This change ensures that we update the `minimum-scale` size when the overflow
of the ICB changes.
Differential Revision: https://phabricator.services.mozilla.com/D226416
On mobile environments, the `minimum-scale` size, which allows users to zoom
out to scales less than 1.0, should include the ICB's overflow, even when
`overflow-x:hidden` is specified on the root element.
This change ensures that we update the `minimum-scale` size when the overflow
of the ICB changes.
Differential Revision: https://phabricator.services.mozilla.com/D226416
It's not needed, ReflowFinished runs less often but still
unconditionally for scroll containers when we reflow, so it's a fine
place to post async work.
Differential Revision: https://phabricator.services.mozilla.com/D226116
