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
That's what we use for painting in all platforms except macOS with
overlay scrollbars, where we make it sticky. Make the stickiness more
explicit (this also fixes the sticky state getting cleaned up too
early).
Differential Revision: https://phabricator.services.mozilla.com/D222161
This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
Most frame types have identical or very similar implementation for GetMinISize()
and GetPrefISize(), and many of them already have `IntrinsicISize()` to unify
the implementation. This patch introduces nsIFrame::IntrinsicISize() so that
derived classes only need to override one method.
`nsBlockFrame`, `ColumnSetWrapperFrame`, and `nsColumnSetFrame` are the only
three classes where their `GetMinISize()` and `GetPrefISize()` have significant
differences. Therefore, we rename `GetMinISize()` and `GetPrefISize()` to
`MinISize()` and `PrefISize`, respectively, and use them as helpers to implement
their `IntrinsicISize()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D217790
It's a rather useless interface:
* nsITextControlFrame is only implemented by nsTextControlFrame, so we
can just use that.
* nsIFormControlFrame had very few actual functionality, mostly
scattered around:
* SetFormProperty(select) was only useful for nsTextControlFrame.
* SetFormProperty(value) was only called on file controls.
* SetFocus() did mostly nothing, or things that can be done in
ElementStateChanged instead.
There are some do_QueryFrame calls that I replaced for better checks in
font inflation and nsIFrame, but I'll adjust to preserve behavior if you
insist (it just such a somewhat-random check).
Differential Revision: https://phabricator.services.mozilla.com/D217322
We rely on positioning ancestors before descendants to get the right
position. This was very implicitly enforced before the regressing bug,
by reframing on position changes (due to the order
StickyScrollContainer::AddFrame was called, ancestors before children).
In order to support dynamic sticky changes without reframing, we need to
handle the case of an existing ancestor switching position to sticky
dynamically.
Luckily we already have the right data-structure for that, so the change
is rather trivial.
Write a testharness test for this because APZ does get the position
right, so it's more future-proof against regressions to just test the
raw layout values.
Differential Revision: https://phabricator.services.mozilla.com/D216858
Chrome uses bimodal layout viewport for IntersectionObserver;
a) While the dynamic toolbar is visible, Chrome uses the layout viewport
(which doesn't include the dynamic toolbar area)
b) While the dynamic toolbar is completely hidden, Chrome uses the layout
viewport + the height that the dynamic toolbar was originally occupied.
In this change we align the behavior with Chrome's behavior.
Differential Revision: https://phabricator.services.mozilla.com/D212920
This change is basically equivalent with what we did for bug 1788029 but for
`scroll-snap-align: start` cases.
The test case was originally written by Daniel Holbert.
Differential Revision: https://phabricator.services.mozilla.com/D215315
