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
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
This patch moves the documentation from `nsIScrollableFrame.h` to
`ScrollContainerFrame.h`. We keep methods in the original order as they were in
`nsIScrollableFrame`.
Differential Revision: https://phabricator.services.mozilla.com/D211500
The motivation of this patch is that we've now switched all the callers from
`nsIScrollableFrame` to `ScrollContainerFrame`, and it is better to audit the
access control of `ScrollContainerFrame`'s interface, and I notice almost all
the member variables are public!
This patch shuffle the interface so that there are only one public, protected,
and private section, and all the member variables are moved to the private
section.
`AutoMinimumScaleSizeChangeDetector` and `RemoveDisplayPortCallback` need to
access member variables, so by declaring them under `ScrollContainerFrame`, they
have the privilege to do so.
Ideally, the caller only need to access what are already in
`nsIScrollableFrame`, so currently we might expose more methods than necessary.
We can audit that in a later part.
Differential Revision: https://phabricator.services.mozilla.com/D211499
This is a preparation to remove `#include "nsIScrollableFrame.h"` for
ScrollTimeline.cpp and ViewTimeline.cpp.
Move the implementation of `nsListControlFrame::GetMultiple()` to cpp. Keeping
it inline requires adding `#include "mozilla/dom/Element.h"` in the header, and
I don't feel the method is hot enough to be inlined.
Differential Revision: https://phabricator.services.mozilla.com/D211492
In theory, changing the return type from `nsIFrame*` to `ScrollContainerFrame*`
exposes `ScrollContainerFrame` to the callers who might not needed, but almost
all of the callers in cpp files are already exposed to `nsIScrollableFrame`, as
demonstrated in this patch via replacing the #include from
"nsIScrollableFrame.h" to "ScrollContainerFrame.h", so this is OK.
Some callers can be simplified since we no longer need `do_QueryFrame` to
`nsIScrollableFrame`.
Differential Revision: https://phabricator.services.mozilla.com/D211488
