This patch is intended to be mechanical, just adding the new keyword as an
alias for the existing behavior, basically.
In a later bug, 'stretch' will gain additional capabilities before we enable
the pref. After that, I intend to ultimately make '-moz-available' an alias of
'stretch', assuming that doing so is web-compatible.
Differential Revision: https://phabricator.services.mozilla.com/D217686
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
The OFFSET_BY_ORIGIN flag just makes GetResultingTransformMatrix PostTranslate the result by the nsPoint we pass to it, which is (0,0), so this is useless and does take time.
Differential Revision: https://phabricator.services.mozilla.com/D217207
This matches the current shipping version of Chromium, and the last
version of the spec, except for the <slot> display when open, which per
spec ought to be `block`, but it's still `contents`.
animation-canceled-by-parent-details-element-being-closed.html is
invalid because content-visibility doesn't cancel animations, just
pauses them. It also times out in Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D217192
This matches the current shipping version of Chromium, and the last
version of the spec, except for the <slot> display when open, which per
spec ought to be `block`, but it's still `contents`.
animation-canceled-by-parent-details-element-being-closed.html is
invalid because content-visibility doesn't cancel animations, just
pauses them. It also times out in Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D217192
Like bug 1907871 (which covered the non transformed case) but for the transformed case where we are just getting the offset to the parent frame. Should be a little faster.
Differential Revision: https://phabricator.services.mozilla.com/D217195
The problems in the testcase are, `nsIFrame::PeekOffsetForLine` returns a frame
for any content node outside the editing host and `nsIFrame::GetLastLeaf`
returns a native anonymous subtree node if the frame is for the native
anonymous subtree root like `<input>` or `<textarea>`.
For fixing the former, the methods need to check whether found frame's editable
state **and** whether the editable node is an inclusive descendant of the
editing host. However, there are complicated cases with inline editing hosts
and elements whose `contenteditable` is set to `false` and this is a new
regression for ESR 128. Therefore, we need to fix this without any behavior
changes as far as possible. Therefore, this patch basically checks only whether
the editing state of found one is editable and/or whether the one is an
inclusive descendant of the editing host to avoid `Selection` moves outside the
editing host. The reaming complicated cases should be handled in new bugs which
blocks bug 1873155.
For fixing the latter, `nsIFrame::GetLastLeaf` needs to check the given frame's
content is a native anonymous subtree root or not.
Differential Revision: https://phabricator.services.mozilla.com/D216371
I checked crash stats to see if we ever hit this MOZ_CRASH: it's very rare, and the handful of crashes I found came from callsites where that was impossible (ie the two frames we are getting offsets between were derived by calling GetCrossDocParentFrame). The crashes did however have the feel of those layout crashes that seem like bad hardware etc (ie some crashes have non-zero bitflip chance, other weird things).
Differential Revision: https://phabricator.services.mozilla.com/D216550
The call is relatively heavy, and it avoids extra function calls. We only stop at zoomed content roots if the viewport type is visual. This code was added in bug 1556556; that context tells us why the code was added so we can be sure this stop is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D215864
Bug 1801025 removed any special handling for popups in this function, but we didn't remove popups from the stopping conditions. Skipping the call saves some time, and also avoids extra function calls.
Differential Revision: https://phabricator.services.mozilla.com/D215863
nsIFrame::GetTransformMatrix returns a Matrix4x4Flagged (a matrix with a type field signifying if it is identity, simple 2d matrix, or full 3d matrix so operations can be simplified) but we construct simple Matrix4x4 and return them, which forces us to construct a Matrix4x4Flagged and Analyze() it to determine what type it is. We should just construct a flagged matrix directly. This shows up in profiles.
GetTransformMatrix got converted from Matrix4x4 to Matrix4x4Flagged for perf reasons in the past, so that explains how we ended up in this situation.
We still use Matrix4x4 in the more complicated actually transformed case.
Differential Revision: https://phabricator.services.mozilla.com/D215867
`nsIFrame` already provides `GetIntrinsicSize()` for subclasses to override.
Therefore, `nsLeafFrame` doesn't need to introduce another version for its
subclasses.
This patch (hopefully) shouldn't change the behavior.
Differential Revision: https://phabricator.services.mozilla.com/D215998
See https://drafts.csswg.org/css-sizing-4/#aspect-ratio-minimum
The flex container and grid container have already considered max sizes clamping
when computing their sizes. Therefore, `flex-aspect-ratio-043.html`,
`flex-aspect-ratio-044.html`, and `grid-aspect-ratio-042.html` already pass on
the current Nightly without this patch.
- `flex-aspect-ratio-043.html` and `flex-aspect-ratio-044.html` are adapted from
`flex-aspect-ratio-040.html` and `flex-aspect-ratio-041.html`.
- `grid-aspect-ratio-042.html` is adapted from `grid-aspect-ratio-039.html`.
- `fieldset-element-002.html` is adapted from `fieldset-element-001.html`.
Differential Revision: https://phabricator.services.mozilla.com/D215296
`ComputeISizeValue()` used to take `StyleSizeOverrides`, but
This patch reflects the fact that intrinsic inline size value such as
'min-content', 'max-content', etc. can be resolved via a definite block size and
a preferred aspect-ratio.
For the callers in `nsIFrame::ComputeSize()` and
`nsContainerFrame::ComputeSizeWithIntrinsicDimensions()`, we can pass the
`styleBSize` and `aspectRatio` that have considered the size overrides.
Also, simplify `ComputeISizeValueFromAspectRatio()` so that it can be reused in
other places. We'll adapt more callers in the next part. Note that the `aFlags`
parameter is unused, so it is removed.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D215294
Rename `aContainingBlockSize` to `aCBSize` for brevity, which also matches the
parameter naming in `ComputeSize()` and `ComputeAutoSize`.
Add a helper lambda `GetAvailableISize()` to compute the available inline size.
Mark the `ComputeISizeValue()` resolving `LengthPercentage` as `const`.
Differential Revision: https://phabricator.services.mozilla.com/D215293
This patch is a revert of
https://hg.mozilla.org/mozilla-central/rev/8ea9b9da6922 because the correctness
assumption described in the commit message was wrong. Note that this patch does
not revert the documentation improvement for
`nsSplittableFrame::RemoveFromFlow()` because it is worth keeping.
During frame destruction, `nsBlockFrame::MarkIntrinsicISizesDirty()` can be
called and it accesses `FirstContinuation()`. Thus, it is not acceptable to
allow a stale first-continuation cache during frame destruction.
Differential Revision: https://phabricator.services.mozilla.com/D214658
This comes back to ~since forever, since absolutely positioned elements
used to have views. But now is basically only plumbed from
nsMenuPopupFrame to nsIWidget.
The main issue is that that concept is basically fiction nowadays:
* Wayland can't reorder popups.
* macOS doesn't implement it because SetZIndex calls PlaceBehind which
only has a windows impl.
* Unclear whether it works properly on Windows as well.
Also, the front-end never sets it anyways.
So remove this fiction to simplify relevant code. We might want to
provide a z-ordering of popups somehow else, but it should probably live
in nsXULPopupManager etc rather than nsView.
Differential Revision: https://phabricator.services.mozilla.com/D213598
The correctness assumption for this patch is that we destroy all frame
continuations when removing an element, so any stale first continuation cache
during frame destruction is acceptable.
Differential Revision: https://phabricator.services.mozilla.com/D213686
`GetAspectRatio()` considers both the `aspect-ratio` property and the intrinsic
aspect-ratio of replaced elements.
Changing just `nsIFrame::ComputeISizeValueFromAspectRatio()` fixed the intrinsic
size for replaced elements when there is a definite height. However, it doesn't
pass any tests on wpt, so I wrote intrinsic-size-017.html to
intrinsic-size-019.html to cover this.
Modifying `nsLayoutUtils::IntrinsicForAxis()` fixed the intrinsic size
contribution for replaced elements. We already have the logic to use inline size
from aspect ratio in `AddIntrinsicSizeOffset()` and `GetIntrinsicCoord()`. We
just need to compute it when sizes in the inline axis have intrinsic keywords.
intrinsic-size-020.html to intrinsic-size-025.html cover this.
grid-auto-min-sizing-min-content-min-size-{001,002}-ref.html are also modified
to reflect this new behavior. The modified subtests are:
- 001.html: Test 1, 2, 3, 6, 8, 9
- 002.html: Test 1, 2, 3, 6, 7, 9
In these modified subtests, before this patch, our rendering was all different
from Google Chrome's. After this patch, our behavior aligns with Google Chrome,
except for Test 7 and 9 in 002.html.
Differential Revision: https://phabricator.services.mozilla.com/D212716
This renaming is to match the existing `ComputeISizeValue()` and
`ComputeBSizeValue()` APIs. Also, rename the related local variables for brevity
and improve the comments.
Differential Revision: https://phabricator.services.mozilla.com/D212715
The `IsReplacedWithBlock()` method is used only in
`ShouldApplyOverflowClipping()`, which determines the overflow clip axes. Since
we've already enumerated the frame types that need overflow clipping, we can
just add more types that had `ReplacedContainsBlock` flag to the switch-cases
and remove the flag.
Differential Revision: https://phabricator.services.mozilla.com/D212199
This also makes `PhysicalAxis::{Horizontal,Vertical}` more useful when we
previous needed `PhysicalAxes::{Horizontal,Vertical}`.
Differential Revision: https://phabricator.services.mozilla.com/D211941
`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
Convert `nsIScrollableFrame` to `ScrollContainerFrame` for all the APIs in
nsLayoutUtils, and then adapt other callers until everything compiles.
In `nsLayoutUtils::CalculateBasicFrameMetrics()`'s documentation,
s/ComputeFrameMetrics/ComputeScrollMetadata/ because the method was renamed in
https://hg.mozilla.org/mozilla-central/rev/cb2023f50288
Differential Revision: https://phabricator.services.mozilla.com/D211493
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 also makes `PhysicalAxis::{Horizontal,Vertical}` more useful when we
previous needed `PhysicalAxes::{Horizontal,Vertical}`.
Differential Revision: https://phabricator.services.mozilla.com/D211941
This also makes `PhysicalAxis::{Horizontal,Vertical}` more useful when we
previous needed `PhysicalAxes::{Horizontal,Vertical}`.
Differential Revision: https://phabricator.services.mozilla.com/D211941
`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
Convert `nsIScrollableFrame` to `ScrollContainerFrame` for all the APIs in
nsLayoutUtils, and then adapt other callers until everything compiles.
In `nsLayoutUtils::CalculateBasicFrameMetrics()`'s documentation,
s/ComputeFrameMetrics/ComputeScrollMetadata/ because the method was renamed in
https://hg.mozilla.org/mozilla-central/rev/cb2023f50288
Differential Revision: https://phabricator.services.mozilla.com/D211493
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
