A percentage basis is needed to resolve percentage block size when computing
children's intrinsic inline size contributions. This is necessary for a child or
descendants with a preferred aspect-ratio so that the block size can transfer
through the aspect-ratio to become an intrinsic inline size.
The change in `nsFlexContainerFrame::ComputeIntrinsicISize()` is necessary to
keep us passing
`testing/web-platform/tests/css/css-flexbox/image-nested-within-definite-column-flexbox.html`.
The change in `nsPlaceholderFrame::AddFloatToIntrinsicISizeData()` is necessary
to keep us passing
`testing/web-platform/tests/css/css-sizing/intrinsic-percent-replaced-dynamic-010.html`.
`GetISizeInfo()` in BasicTableLayoutStrategy.cpp is modified to pass table cell
frame's bsize as percentage basis. Otherwise,
`layout/reftests/bugs/522632-1.html` fails. This is our current behavior, but it
is bug 1461852.
Differential Revision: https://phabricator.services.mozilla.com/D219523
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
A percentage basis is needed to resolve percentage block size when computing
children's intrinsic inline size contributions. This is necessary for a child or
descendants with a preferred aspect-ratio so that the block size can transfer
through the aspect-ratio to become an intrinsic inline size.
The change in `nsFlexContainerFrame::ComputeIntrinsicISize()` is necessary to
keep us passing
`testing/web-platform/tests/css/css-flexbox/image-nested-within-definite-column-flexbox.html`.
The change in `nsPlaceholderFrame::AddFloatToIntrinsicISizeData()` is necessary
to keep us passing
`testing/web-platform/tests/css/css-sizing/intrinsic-percent-replaced-dynamic-010.html`.
`GetISizeInfo()` in BasicTableLayoutStrategy.cpp is modified to pass table cell
frame's bsize as percentage basis. Otherwise,
`layout/reftests/bugs/522632-1.html` fails. This is our current behavior, but it
is bug 1461852.
Differential Revision: https://phabricator.services.mozilla.com/D219523
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
We no longer need the concept of "local" transforms after bug 878346.
Local transforms that we'd need in the future could be represented via
attribute mapping.
We still need the viewbox transform shenanigans which applies to
children only, tho.
Differential Revision: https://phabricator.services.mozilla.com/D220290
`HTMLEditor::FinalizeSelection()` resets the caret and `nsCaret` schedules to
paint itself with the new state. If editing host is being removed, it's already
been removed from the child chain of its parent but it still knows the parent.
Additionally, `nsCaret` may still keep storing the removing editing host as the
content. In such case, we try to look for the line edge from the removing
editing host and fails to compute the index in its parent node for considering
the caret geometry. For avoiding to compute it in the unstable period,
`nsFocusManager::ContentRemoved()` should call `HTMLEditor::FinalizeSelection()`
after the removal ends.
Differential Revision: https://phabricator.services.mozilla.com/D219845
There were added in bug 1436505. Nowadays they show up large in profiles, eg bug 1466704.
I checked crash stats, we aren't hitting these.
Differential Revision: https://phabricator.services.mozilla.com/D220052
Generally we want to move to more flagged matrices because the transforms are usually simple, just offsets, or simple 2d transforms and the operations do show up in profiles if we do them in the "dumb" way of assuming a full 3d transform.
This specific code isn't necessarily performance critical, but it simplifies nsIFrame::GetTransformMatrix (which is performance critical) so that everything there is Matrix4x4Flagged except the one conversion for GetResultingTransformMatrix.
Matrix4x4TypedFlagged::ToUnknownMatrix gets its first user with this change and we need to make some fixes so that it actually works. We need to friend all template instantiations of this class so that it can access the private constructor of the class with different units. We also need to move the MatrixType enum outside of the class so it doesn't get the templated units imprinted on its type. Maybe there is a better way to do this.
Differential Revision: https://phabricator.services.mozilla.com/D218018
The background image is associate to the table frame, but the table wrapper frame is the primary frame, thus IsPrimaryFrameOfRootOrBodyElement returns false and we don't propagate to the root when we should. So I changed IsPrimaryFrameOfRootOrBodyElement to handle this case and renamed it. I checked the other root element frame types, only table frames had this issue.
Differential Revision: https://phabricator.services.mozilla.com/D217923
Ensure that when we construct a wrapping surface for a transform
due to a complex clip, we mark it as wrapping a backdrop-filter
when that is required.
Differential Revision: https://phabricator.services.mozilla.com/D217922
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
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
Ting-Yu Lin