The TextNodeCorrespondenceRecorder stuff doesn't handle display: contents or
Shadow DOM at all. This causes a failure with an upcoming patch.
This patch fixes it and fixes related crashes like bug 1563779. This is the same
wallpaper as bug 1421807.
Differential Revision: https://phabricator.services.mozilla.com/D49138
I use `warningFlag` instead of `infoFlag` because even if the principal
writing-mode propagation is written in the spec, its effect might
surprise the developers.
Differential Revision: https://phabricator.services.mozilla.com/D48774
I'm not happy about all the SVG text / disallow out of flow complexity sprinkled
during frame construction... :(
Maybe we should add some kind of more generic mechanism to disallow some
children for particular kinds of frames, or something.
Co-authored-by: Mats Palmgren <mats@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D44808
When XBL is disabled, no code in dom/xbl will be built. Also, adds ifdefs
to remove any of the XBL related code elsewhere. There's definitely more
that can be done here, but I think it's better to wait to do the rest of
the cleanup when we actually remove the code.
Depends on D45612
Differential Revision: https://phabricator.services.mozilla.com/D45613
If a <details> is a multi-column container, and has a column-span child
inside, aFrame can be ColumnSetWrapper or column-span-wrapper frame (due
to GetInsertionPrevSibling()'s modification). The latter case is handled
by "Situation #5 in WipeContainingBlock(), and can be reproduced by
changing `<article>` tag to `<details>` in
testing/web-platform/tests/css/css-multicol/multicol-span-all-dynamic-add-005.html
In any case, aFrame might end up in a frame generated by the <details>
element. I feel the assertion to check frame types might not be very
useful. Let's remove it.
Differential Revision: https://phabricator.services.mozilla.com/D45585
If the <details> has ::first-letter, insertion.mParentFrame may be
modified by GetInsertionPrevSibling(), and points to nsFirstLetterFrame.
Fortunately, nsFirstLetterFrame's content is the details element. We can
check the content to determine if reframing the <details> is needed.
Also, add a reftest to test that an appended text should apply styles in
details::first-line.
Differential Revision: https://phabricator.services.mozilla.com/D45454
This condition was needed when FindInsertionPrevSibling and co didn't understand
display: contents.
Editor is pretty broken (and calls into PresShell::ContentRemoved directly, and
incorrectly, using anonymous nodes).
In this case we were taking the XBL path because of display: contents, which
means that we tried to seek to the editor anonymous node, and crash (since it's
not an explicit kid).
Editor needs to get fixed, but this is technically more correct and fixes the
crash, so we may as well take it in the interim.
Differential Revision: https://phabricator.services.mozilla.com/D42472
Resolution is at:
* https://github.com/w3c/csswg-drafts/issues/3779#issuecomment-481762912
Tests are at https://chromium-review.googlesource.com/c/chromium/src/+/1547974,
I'll make sure to wait until they're in the tree and ensure they're passing.
Note that we need to ensure in the frame constructor that the document element
is styled _before_ calling UpdateViewportScrollStylesOverride(). This saves
duplicated work (since ResolveStyleLazily throws away the style).
ResolveStyleLazily already returns out of date styles, unless the element is not
styled yet, or is in a `display: none` subtree, in which case it computes and
returns a new (up-to-date) style.
So the switch to the FFI call only should change behavior for the display: none
subtree case (since we ensure the unstyled case isn't hit by styling the
document earlier). But that case is one of the cases we're interested in
changing, conveniently.
Depends on D40080
Differential Revision: https://phabricator.services.mozilla.com/D39204
Return a raw pointer instead of a strong reference to a ComputedStyle, and
handle the case of the style not being present by returning null rather than
requiring an extra function to check it and crashing if the precondition is not
met.
Also, name them so that it's clear they just return outdated styles and don't
make any extra effort.
This is just cleanup that makes the next patch easier / more obvious.
Differential Revision: https://phabricator.services.mozilla.com/D40080
It was made pointless by the previous patch.
This replaces callers that had a frame type for another reason with the
frame type check that IsTableCell did, and callers that needed to call
Type() with an IsTableCellFrame call.
Differential Revision: https://phabricator.services.mozilla.com/D40561
We want mHasColumnSpanSiblings to propagate to all the
continuations (both fixed ones or fluid ones) in nsFrame::Init() so that
we don't need to traverse all the way to FirstInFlow() for the bit in
nsBlockFrame::ComputeFinalBSize().
For the last ColumnSet or the last non-column-span wrapper, we'll need
to unset the bit for them manually after constructing them.
Differential Revision: https://phabricator.services.mozilla.com/D40761
We naively remove and then recreate accessibles when their content's
frame is reconstructed. By delaying the removal until we are certain the
content does not have a new layout frame, we can cut down on redundant
recreations.
When reconstructed content is re-inserted we can check it and its
subtree for missing frames and prune those accessibles from the tree.
Differential Revision: https://phabricator.services.mozilla.com/D38380
These frame state bits belong to the generic group, and there is
existing logic in nsFrame::Init() for carrying frame state bits. It's
better to consolidate them in one place.
Differential Revision: https://phabricator.services.mozilla.com/D40244
After enabling column-span, ColumnSet becomes an anonymous child under
ColumnSetWrapperFrame. It doesn't need to handle border and padding,
containment, and non-auto block-size. ColumnSet's final block-size is
simply the union of ::-moz-column-content frames' rects.
However, we should extend ColumnSet's block-size to consume the
available block-size if the ColumnSetWrapper's block-size is constrained
so that the column rules are drawn to the block-end edge of the multicol
container.
Differential Revision: https://phabricator.services.mozilla.com/D39060
After enabling column-span, ColumnSet becomes an anonymous child under
ColumnSetWrapperFrame. It doesn't need to handle border and padding,
containment, and non-auto block-size. ColumnSet's final block-size is
simply the union of ::-moz-column-content frames' rects.
However, we should extend ColumnSet's block-size to consume the
available block-size if the ColumnSetWrapper's block-size is constrained
so that the column rules are drawn to the block-end edge of the multicol
container.
Differential Revision: https://phabricator.services.mozilla.com/D39060
