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
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
Ting-Yu Lin