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
This is the only -moz-box special-case that isn't related to the
visibility: collapse behavior.
After this is done, we can put the collapse behavior in a chrome-only
property, and remove the -moz-box display values and migrate the
-moz-box properties to modern flexbox automatically.
Differential Revision: https://phabricator.services.mozilla.com/D170813
Testcase 001 and 002 test row-oriented and column-oriented flex container,
respectively. The "a" and "b" variant test `box-sizing:border-box` and
`box-sizing:content-box`, respectively.
Differential Revision: https://phabricator.services.mozilla.com/D170035
It's a more natural place for it to live, since it concerns only the
root view.
Clean up a bit while at it, and factor out the window size constraints,
which we're going to use momentarily.
Differential Revision: https://phabricator.services.mozilla.com/D168461
Make it return a margin from client area to window area, and add an
explicit function to get the size difference.
No behavior change.
Depends on D166428
Differential Revision: https://phabricator.services.mozilla.com/D166431
Move it to the mozilla::widget namespace.
Use enum classes for transparency, popup type, popup level, etc.
Mostly automated with sed, but there were a few manual changes required
as well in windows code because they relied on Atomic<TransparencyMode>
working (which now doesn't because TransparencyMode is 1 byte instead of
4 bytes).
Differential Revision: https://phabricator.services.mozilla.com/D167537
Make it return a margin from client area to window area, and add an
explicit function to get the size difference.
No behavior change.
Depends on D166428
Differential Revision: https://phabricator.services.mozilla.com/D166431
They have been disabled since bug 1688695. There's a variety of
table-caption bugs that would be easier to fix if we didn't have to
account for side-captions.
Differential Revision: https://phabricator.services.mozilla.com/D165690
They have been disabled since bug 1688695. There's a variety of
table-caption bugs that would be easier to fix if we didn't have to
account for side-captions.
Differential Revision: https://phabricator.services.mozilla.com/D165690
They have been disabled since bug 1688695. There's a variety of
table-caption bugs that would be easier to fix if we didn't have to
account for side-captions.
Differential Revision: https://phabricator.services.mozilla.com/D165690
Ting-Yu Lin