This patch doesn't change user-perceivable behavior.
Note: before this patch, when reflowing poster frame, `kidReflowInput` was
initialized with `cbSize` of value (0,0), which is bogus since `Size` in
`aMetrics` has not been set yet. Removing the bogus code uncovers the following
assertions
```
ASSERTION: Our containing block must not have unconstrained inline-size!
```
in a 944909-1.html, which has bogus large sizes.
Differential Revision: https://phabricator.services.mozilla.com/D189084
This patch doesn't change user-perceivable behavior.
Note: before this patch, when reflowing poster frame, `kidReflowInput` was
initialized with `cbSize` of value (0,0), which is bogus since `Size` in
`aMetrics` has not been set yet. Removing the bogus code uncovers the following
assertions
```
ASSERTION: Our containing block must not have unconstrained inline-size!
```
in a 944909-1.html, which has bogus large sizes.
Differential Revision: https://phabricator.services.mozilla.com/D189084
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
We still have some remnants of XUL layout due to nsBox / nsLeafBoxFrame
which XUL trees / nsTextBoxFrame still use.
However all this code can go away before we get rid of those.
nsSplitterFrame was the last thing inheriting from nsBoxFrame.
Differential Revision: https://phabricator.services.mozilla.com/D173601
C++20 deprecates some operations between enums and floating point types:
https://clang.llvm.org/docs/DiagnosticsReference.html#wenum-float-conversion
dom/canvas/CanvasRenderingContext2D.cpp:4743:58 [-Wenum-float-conversion] arithmetic between enumeration type 'VideoInfo::Rotation' and floating-point type 'double'
dom/events/EventStateManager.cpp:6656:35 [-Wenum-float-conversion] comparison of floating-point type 'double' with enumeration type 'mozilla::EventStateManager::(unnamed enum at dom/events/EventStateManager.h:342:3)'
dom/events/EventStateManager.cpp:6664:35 [-Wenum-float-conversion] comparison of floating-point type 'double' with enumeration type 'mozilla::EventStateManager::(unnamed enum at dom/events/EventStateManager.h:342:3)'
gfx/thebes/gfxTextRun.cpp:2992:24 [-Wenum-float-conversion] comparison of floating-point type 'gfxFloat' (aka 'double') with enumeration type 'gfxFontGroup::(unnamed enum at gfx/thebes/gfxTextRun.h:1035:3)'
layout/generic/nsVideoFrame.cpp:59:58 [-Wenum-float-conversion] arithmetic between enumeration type 'VideoInfo::Rotation' and floating-point type 'double'
layout/painting/nsCSSRenderingBorders.cpp:2752:27 [-Wenum-float-conversion] arithmetic between enumeration type 'mozilla::Corner' and floating-point type 'double'
Differential Revision: https://phabricator.services.mozilla.com/D158867
This will allow this function to eventually return an appropriate value
depending on whether or not content is skipped via `content-visibility:
auto`. This change also starts looking directly at whether
content-visibility is skipping content or not, which should make it
compatible with a future `content-visibility: auto` implementation.
Differential Revision: https://phabricator.services.mozilla.com/D157831
Some anonymous children are important for properly sizing their parents
even when those parents hide content with `content-visibility`. This is
shown by regressions in the proper layout of some form elements with
`content-visibility`.
This change introduces a more conservative approach for avoiding layout
of hidden content. Instead of leaving all children dirty during reflow,
reflow anonymous frames (and nsComboboxDisplayFrame, a specialized kind
of anonymous frame). This change means that frames may only lay out some
of their children, so it must introduce some more changes to assumptions
during line layout.
In addition, this change renames `content-visibility` related methods in
nsIFrame in order to make it more obvious what they do.
Differential Revision: https://phabricator.services.mozilla.com/D157306
Some anonymous children are important for properly sizing their parents
even when those parents hide content with `content-visibility`. This is
shown by regressions in the proper layout of some form elements with
`content-visibility`.
This change introduces a more conservative approach for avoiding layout
of hidden content. Instead of leaving all children dirty during reflow,
reflow anonymous frames (and nsComboboxDisplayFrame, a specialized kind
of anonymous frame). This change means that frames may only lay out some
of their children, so it must introduce some more changes to assumptions
during line layout.
In addition, this change renames `content-visibility` related methods in
nsIFrame in order to make it more obvious what they do.
Differential Revision: https://phabricator.services.mozilla.com/D157306
Some anonymous children are important for properly sizing their parents
even when those parents hide content with `content-visibility`. This is
shown by regressions in the proper layout of some form elements with
`content-visibility`.
This change introduces a more conservative approach for avoiding layout
of hidden content. Instead of leaving all children dirty during reflow,
reflow anonymous frames (and nsComboboxDisplayFrame, a specialized kind
of anonymous frame). This change means that frames may only lay out some
of their children, so it must introduce some more changes to assumptions
during line layout.
In addition, this change renames `content-visibility` related methods in
nsIFrame in order to make it more obvious what they do.
Differential Revision: https://phabricator.services.mozilla.com/D156473
In the description of the mTruncated bit, its purpose is the same as calling
SetInlineLineBreakBeforeAndReset(). We've removed all its usages in previous
patches, so the bit is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D151461
ContainSizeAxes::ContainSize and ContainSizeAxes::ContainIntrinsicSize
were just using 0 for the axes with size containment, now they will take
contain-intrinsic-width and contain-intrinsic-height into account.
The WritingMode parameter is replaced with a nsIFrame from which the
properties are retrieved.
There are various places that aren't currently using these functions, so
the effect of this patch is rather minimal, but some cases of the new
test are now passing.
Differential Revision: https://phabricator.services.mozilla.com/D152355
ReflowFinished can happen with scripts allowed, so make sure not to
synchronously fire events, as they can fire content microtasks which
could destroy the frame.
Differential Revision: https://phabricator.services.mozilla.com/D146668
Fix regression from returning zero intrinsic size for audio
elements, which caused the element to be positioned incorrectly
in absolutely positioned, orthogonal flow situations.
Differential Revision: https://phabricator.services.mozilla.com/D144182
There are two cases for the audio element:
1. audio element with "controls" - replaced element (but UA shouldn't
show the content. Only control UI there.)
2. audio element without "controls" - UA sets display:none.
Per spec, if a replaced element’s only natural dimension is a natural width or
a natural height, giving it a preferred aspect ratio also gives it an natural
height or width, whichever was missing, by transferring the existing size
through the preferred aspect ratio.
However, the audio element (with or without "controls") doesn't have the
natural ratio and natural size. I think it's a special case and it doesn't
make sense to apply aspect-ratio to it even though we specify a width or
height.
Blink and Webkit don't apply aspect-ratio to audio element, either. So
let's follow other browsers' behavior.
Differential Revision: https://phabricator.services.mozilla.com/D118245
This takes the logic used for Image/CanvasLayer::ComputeEffectiveTransforms and uses it to get matching rendering for the Paint path.
Depends on D122175
Differential Revision: https://phabricator.services.mozilla.com/D122176
