This doesn't yet expose it to a11y but that will be done by the a11y
folks, since this blocks some of the a11y interop test-cases.
Modify the tests to not hit the network, and make -moz-alt-content not
exposed to content (we only need it for UA stylesheets).
Differential Revision: https://phabricator.services.mozilla.com/D209690
The two macros are used in `GetPrefISize()` and `GetMinISize()` implementations.
After removing them, we could further simplify some implementations because we
don't need a `result` variable in many cases.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D206316
Values were static_casted where required. Some functions in WritingModes.h were
rewritten such that bitwise operations aren't being used. Added static_casts to
avoid (debug) build errors from debugging printfs in layout/tables/nsCellMap.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D205510
Put all the "is this block a BFC" logic in nsBlockFrame.cpp.
The CLIP_PAGINATED_OVERFLOW flag is also redundant, it can just be "has
non-propagated overflow styles" check in ShouldApplyOverflowClipping(),
and frees another bit.
Shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D203590
<select> doesn't allow first-line, which was causing some non-fatal
asserts.
The annotated crashtest overflows a bSize but it gets handled safely by
nsLineLayout.
MANUAL PUSH: Trivial orange fix CLOSED TREE
This simplifies our combobox code a bit more:
* Reflow() is only needed to compute the label isize.
* Frame construction uses a setup more similar to <input type=file> to
get the right frame tree, removing a bunch of special code.
* Lots of special code removed all over the place.
Differential Revision: https://phabricator.services.mozilla.com/D203010
This is Fantasai's original patch, massively simplified:
* We now can switch whether we're a BFC dynamically (bug 1765615), which
simplifies the patch quite a lot.
* I removed some changes that were specific to pagination but were untested.
I left them as D202814, just in case we need some of those in the future.
All in all this makes the patch much more manageable.
Co-authored-by: Emilio Cobos Álvarez <emilio@crisal.io>
Differential Revision: https://phabricator.services.mozilla.com/D181858
This happens in a similar location to where we find a breakpoint caused by a
change in page name. However, if the breakpoint was caused by something else,
we still need to compute this value so that the next page being constructed
will have the correct page name.
This also "fixes" the WPT /css/printing/page-name-007-print.html, which passed
before this patch just because our previous logic would continue using the last
page value in those cases, which coincidentally matched what was expected.
Part 2 will include a test that specifically detects this discrepency.
Differential Revision: https://phabricator.services.mozilla.com/D196895
This happens in a similar location to where we find a breakpoint caused by a
change in page name. However, if the breakpoint was caused by something else,
we still need to compute this value so that the next page being constructed
will have the correct page name.
This also "fixes" the WPT /css/printing/page-name-007-print.html, which passed
before this patch just because our previous logic would continue using the last
page value in those cases, which coincidentally matched what was expected.
Part 2 will include a test that specifically detects this discrepency.
Differential Revision: https://phabricator.services.mozilla.com/D196895
The following classes deriving from nsBlockFrame always set
NS_BLOCK_STATIC_BFC in their constructors or initializers:
- nsComboboxControlFrame
- nsFileControlFrame
- nsSelectsAreaFrame
- ColumnSetWrapperFrame
- nsMathMLmathBlockFrame
Do that in nsBlockFrame::Init instead. Behavior is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D199097
Per https://drafts.csswg.org/css-multicol/#columns:
"A multi-column container therefore is a regular block container that
establishes a new independent formatting context"
IsColumnContainerStyle() and BeginBuildingColumns() are currently
used in three places and always together (namely
ConstructFieldSetFrame, ConstructFrameFromItemInternal and the
generic ConstructBlock).
BeginBuildingColumns() asserts that aColumnContent is an nsBlockFrame
and that aComputedStyle corresponds to multi-column container. It
always adds the NS_BLOCK_STATIC_BFC to aColumnContent. It also
makes aColumnContent a `PseudoStyleType::columnContent` and that's
the only place where it's used.
This patch instead makes StyleEstablishesBFC() return true for
PseudoStyleType::columnContent so that the NS_BLOCK_DYNAMIC_BFC bit
is set at init and after further style updates. It thus removes the
need for to explicitly set NS_BLOCK_STATIC_BFC in
BeginBuildingColumns().
There is no behavior changes.
Differential Revision: https://phabricator.services.mozilla.com/D199091
The following classes deriving from nsBlockFrame always set
NS_BLOCK_STATIC_BFC in their constructors or initializers:
- nsComboboxControlFrame
- nsFileControlFrame
- nsSelectsAreaFrame
- ColumnSetWrapperFrame
- nsMathMLmathBlockFrame
Do that in nsBlockFrame::Init instead. Behavior is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D199097
Per https://drafts.csswg.org/css-multicol/#columns:
"A multi-column container therefore is a regular block container that
establishes a new independent formatting context"
IsColumnContainerStyle() and BeginBuildingColumns() are currently
used in three places and always together (namely
ConstructFieldSetFrame, ConstructFrameFromItemInternal and the
generic ConstructBlock).
BeginBuildingColumns() asserts that aColumnContent is an nsBlockFrame
and that aComputedStyle corresponds to multi-column container. It
always adds the NS_BLOCK_STATIC_BFC to aColumnContent. It also
makes aColumnContent a `PseudoStyleType::columnContent` and that's
the only place where it's used.
This patch instead makes StyleEstablishesBFC() return true for
PseudoStyleType::columnContent so that the NS_BLOCK_DYNAMIC_BFC bit
is set at init and after further style updates. It thus removes the
need for to explicitly set NS_BLOCK_STATIC_BFC in
BeginBuildingColumns().
There is no behavior changes.
Differential Revision: https://phabricator.services.mozilla.com/D199091
The following classes deriving from nsBlockFrame always set
NS_BLOCK_STATIC_BFC in their constructors or initializers:
- nsComboboxControlFrame
- nsFileControlFrame
- nsSelectsAreaFrame
- ColumnSetWrapperFrame
- nsMathMLmathBlockFrame
Do that in nsBlockFrame::Init instead. Behavior is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D199097
Per https://drafts.csswg.org/css-multicol/#columns:
"A multi-column container therefore is a regular block container that
establishes a new independent formatting context"
IsColumnContainerStyle() and BeginBuildingColumns() are currently
used in three places and always together (namely
ConstructFieldSetFrame, ConstructFrameFromItemInternal and the
generic ConstructBlock).
BeginBuildingColumns() asserts that aColumnContent is an nsBlockFrame
and that aComputedStyle corresponds to multi-column container. It
always adds the NS_BLOCK_STATIC_BFC to aColumnContent. It also
makes aColumnContent a `PseudoStyleType::columnContent` and that's
the only place where it's used.
This patch instead makes StyleEstablishesBFC() return true for
PseudoStyleType::columnContent so that the NS_BLOCK_DYNAMIC_BFC bit
is set at init and after further style updates. It thus removes the
need for to explicitly set NS_BLOCK_STATIC_BFC in
BeginBuildingColumns().
There is no behavior changes.
Differential Revision: https://phabricator.services.mozilla.com/D199091
Right now, we reconstruct frames in response to a change in the CSS
`contain` property or `content-visibility`. This patch tries to optimize
this a bit:
1. Updates involving style containment change continue to force a
reconstruction, due to the need to handle counters/quotes.
2. Updates involving paint/layout containment change only force a
reconstruction if it's needed to handle absolutely/fixed
positioned descendants or floats (for this one, see also bug 1874826).
3. Other containment changes will only force a reflow and repaint.
Per the CSS contain spec, layout, style and paint containments are
enabled for `content-visibility: hidden` and `content-visibility: auto`.
As a consequence, changing `content-visibility` between `hidden` and
`auto` values no longer requires reconstruction. Changing between these
values and `visible` may need a reconstruction although authors may
generally avoid that in practice by forcing `style` containment.
Differential Revision: https://phabricator.services.mozilla.com/D197043
After D198523, NS_BLOCK_FLOAT_MGR and NS_BLOCK_MARGIN_ROOT are always
set simultaneously when initiating a frame, so we can merge them into a
single NS_BLOCK_STATIC_BFC flag. The freed bit is used to define a new
NS_BLOCK_DYNAMIC_BFC flag that has the same effect and is now used for
frames with paint/layout containment so that in D197043 they can be
updated later without having to reconstruct the frame tree. Finally
NS_BLOCK_BFC_STATE_BITS is the bitwise union of these BFC flags.
The following changes are made and cause no behavior changes:
- Instead of testing whether NS_BLOCK_FLOAT_MGR or NS_BLOCK_MARGIN_ROOT
is set, or whether all of the bits from
NS_BLOCK_FORMATTING_CONTEXT_STATE_BITS are set, we test whether any
of the NS_BLOCK_BFC_STATE_BITS is set.
- Instead of adding NS_BLOCK_FORMATTING_CONTEXT_STATE_BITS when
constructing a frame, we add NS_BLOCK_STATIC_BFC. The exception is
for frame with paint/layout containment, for which we set
NS_BLOCK_DYNAMIC_BFC instead.
Differential Revision: https://phabricator.services.mozilla.com/D198530
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 corresponds to how Chrome behaves, and passes the test they included in WPT.
It's unclear to me whether this behavior actually follows from the current spec
(see https://github.com/w3c/csswg-drafts/issues/9310), but it seems to be the desired
result.
(I've put it behind a (default-enabled) pref for now, so that it's possible to
experiment with the two possible interpretations, but we can remove the pref once
the spec question is clarified/confirmed.)
This patch also disables balancing for fragmented/overflowing blocks, as that will
not currently work well. We may want to address that as a followup issue (though it
won't matter to the primary balance use-cases such as titles).
Depends on D188139
Differential Revision: https://phabricator.services.mozilla.com/D188220
A simple form of balance for short blocks, implemented by incrementally reducing
the effective inline-size used during line-breaking, up to the point where an
extra line would be created.
This fails the test text-wrap-balance-line-clamp-001.html, but it's unclear to me
if that test is correct (see https://github.com/w3c/csswg-drafts/issues/9310).
If we do want the behavior expected by that test, an additional patch to handle
the interaction with line-clamp will be required.
Depends on D187543
Differential Revision: https://phabricator.services.mozilla.com/D187544
This corresponds to how Chrome behaves, and passes the test they included in WPT.
It's unclear to me whether this behavior actually follows from the current spec
(see https://github.com/w3c/csswg-drafts/issues/9310), but it seems to be the desired
result.
(I've put it behind a (default-enabled) pref for now, so that it's possible to
experiment with the two possible interpretations, but we can remove the pref once
the spec question is clarified/confirmed.)
This patch also disables balancing for fragmented/overflowing blocks, as that will
not currently work well. We may want to address that as a followup issue (though it
won't matter to the primary balance use-cases such as titles).
Depends on D188139
Differential Revision: https://phabricator.services.mozilla.com/D188220
A simple form of balance for short blocks, implemented by incrementally reducing
the effective inline-size used during line-breaking, up to the point where an
extra line would be created.
This fails the test text-wrap-balance-line-clamp-001.html, but it's unclear to me
if that test is correct (see https://github.com/w3c/csswg-drafts/issues/9310).
If we do want the behavior expected by that test, an additional patch to handle
the interaction with line-clamp will be required.
Depends on D187543
Differential Revision: https://phabricator.services.mozilla.com/D187544
This corresponds to how Chrome behaves, and passes the test they included in WPT.
It's unclear to me whether this behavior actually follows from the current spec
(see https://github.com/w3c/csswg-drafts/issues/9310), but it seems to be the desired
result.
(I've put it behind a (default-enabled) pref for now, so that it's possible to
experiment with the two possible interpretations, but we can remove the pref once
the spec question is clarified/confirmed.)
This patch also disables balancing for fragmented/overflowing blocks, as that will
not currently work well. We may want to address that as a followup issue (though it
won't matter to the primary balance use-cases such as titles).
Depends on D188139
Differential Revision: https://phabricator.services.mozilla.com/D188220
A simple form of balance for short blocks, implemented by incrementally reducing
the effective inline-size used during line-breaking, up to the point where an
extra line would be created.
This fails the test text-wrap-balance-line-clamp-001.html, but it's unclear to me
if that test is correct (see https://github.com/w3c/csswg-drafts/issues/9310).
If we do want the behavior expected by that test, an additional patch to handle
the interaction with line-clamp will be required.
Depends on D187543
Differential Revision: https://phabricator.services.mozilla.com/D187544
