I stumbled upon this bug while realizing that some of the math I'm doing
for PiP windows doesn't work at all on Linux (bug 1934760), because
screenX != mozInnerScreenX, even though outerWidth == innerWidth.
I've tested this on X11 and Wayland (plasma and Gnome) with CSD and SSD,
and in general, this is the same thing Windows does, so should be fine.
The basic idea is:
* Keep mBounds being frame manager bounds (so, outer* and screen*),
relative to mShell.
* Keep mClientMargin to translate from mBounds to client bounds.
This is both simpler and makes the math consistent.
Differential Revision: https://phabricator.services.mozilla.com/D230981
Note that both keywords are disabled in the CSS parser for now, behind
these about:config prefs:
layout.css.stretch-size-keyword.enabled
layout.css.webkit-fill-available.enabled
Prior to this patch, we handled both keywords as pure aliases for
'-moz-available' (which has the correct 'stretch' behavior in the inline axis
but which just behaves like the initial value in the block axis).
This patch changes that so that 'stretch' and '-webkit-fill-available' will now
actually do the right thing in the block axis (if they're enabled at all, via
their aforementioned about:config prefs).
The relevant spec text here is:
https://drafts.csswg.org/css-sizing-4/#valdef-width-stretchhttps://drafts.csswg.org/css-sizing-4/#stretch-fit-sizing
Differential Revision: https://phabricator.services.mozilla.com/D217688
contain: layout usually makes our kids not account for scrollable
overflow, but when computing scroll{Width,Height} we need to (as the
inner scrolled frame won't use containment).
Add a test for contain: layout + border / padding + various display
types.
After this patch, we only fail the grid ones, due to bug 1797305.
Other browsers also fail a variety of subtests here.
Differential Revision: https://phabricator.services.mozilla.com/D231087
Also implement the alignment safety behaviour that is described as "in-between"
[1].
This is mutually exclusive to `PLACEHOLDER_STATICPOS_NEEDS_CSSALIGN` related computation,
since it involves requiring CSS alignment to compute the static position when inset
values are auto, for grid & flex boxes.
[1] https://drafts.csswg.org/css-position-3/#abspos-layout
Differential Revision: https://phabricator.services.mozilla.com/D226531
After fixing bug 1685428, we honor aspect-ratio under stretch alignment in grid
layout. That makes the enum variants `Stretch` and `StretchPreservingRatio`
confusing.
To clarify their distinct behaviors, this patch renames the enum and its
variants as follows:
* Stretch::NoStretch (eNoStretch) -> FillCB::No
* Stretch::Stretch (eStretch) -> FillCB::Stretch
* Stretch::StretchPreservingRatio (eStretchPreservingRatio) -> FillCB::Clamp
Differential Revision: https://phabricator.services.mozilla.com/D224399
The old code store them in `iSize` and `bSize`, which is confusing since they
can also store the resolved non-auto sizes.
Differential Revision: https://phabricator.services.mozilla.com/D224398
We compute the size of non-replaced elements in `nsIFrame::ComputeSize()` and
replaced elements in `nsContainerFrame::ComputeSizeWithIntrinsicDimensions()`.
When computing a flex item's main-size, we need to skip applying min-main-size
and max-main-size at both functions.
While we still need to duplicate the code in both places, unifying the logic
should make the code easier to read and pave the way for unifying these
functions in the future.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D222905
This patch preserves the aspect-ratio when stretching replaced elements in only
one axis in grid layout, under the condition where the preferred size properties
in both axes behave as 'auto'.
Differential Revision: https://phabricator.services.mozilla.com/D223013
Currently, only the grid container needs the containing block size to resolve
the transferred min and max sizes for `repeat()` function in
`nsGridContainerFrame::ComputeIntrinsicISize()`.
This patch is a preparation for Bug 1865438. `mContainingBlockSize` will be used
there, so it does not change any behavior yet.
Differential Revision: https://phabricator.services.mozilla.com/D221333
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
By adding `ISize()` and `BSize()` to `IntrinsicSize`, we can simplify the
repetitive pattern that checks writing mode and gets the corresponding width or
height.
Differential Revision: https://phabricator.services.mozilla.com/D215047
`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
LogicalAxis is one of the Logical* enums. Converting it from enum to
enum class increases type safety. To run with the pre-existing code,
type casting was added when needed. Comments have been edited where
needed.
Differential Revision: https://phabricator.services.mozilla.com/D206108
The removed reftsts test basically the opposite, and are sufficiently
covered by the WPTs that we start passing, so just remove them.
Differential Revision: https://phabricator.services.mozilla.com/D204797
`prevInFlow.ISize(wm)` has subtracted the margin in the inline-axis. If we use
it as the current overflow container continuation's available inline-size, we
might subtract the margin again when computing its auto inline-size [1], which
leads to progressively compressed inline-size as we see in various testcases.
However, fixing `availSpace` is not correct because not all types of frames
compute their inline-sizes using the available inline-size.
This patch generalizes the solution for flex item in bug 1811548, i.e. we always
override inline-size for the current overflow container continuation.
[1] https://searchfox.org/mozilla-central/rev/ff6e63804e6f7b548a26338708663093ce16be11/layout/generic/nsIFrame.cpp#6736-6737
Differential Revision: https://phabricator.services.mozilla.com/D204580
Remove `prevRect` and comments that don't seem useful; move variable
declarations closer to their usage sites. This is a preparation for Part 2.
This doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D204579
Those callers who using the pointer immediately after getting from
`GetPresShell()` can be replaced with `PresShell()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D199164
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
They shouldn't be doing any work. The only views that exist now are
1) root views
2) menupopup frames
3) subdocument frames and the anonymous inner view directly below them.
The typical ReparentFrameView(List) calls happens during reflow moving something between next in flows. Menupopup frames can't have continuation frames so no next in flows. I audited every call site, none of them should be able to move something out of or into a menupopup frame, and of course none of them should be moving frames across a document boundary.
I left them in as debug only code with unreachable asserts; we can remove it after fuzzers verify that it is unused.
Differential Revision: https://phabricator.services.mozilla.com/D177863
I checked the history, the assert has been commented out since 2000, it was added in 1999. It doesn't seem useful, all the callers basically just get the parent view right before the call.
Differential Revision: https://phabricator.services.mozilla.com/D177862
