Calling nsBlockFrame::ResolveBidi() on ColumnSpanWrapperFrame may cause
nsColumnSetFrame's non-fluid continuations being converted into fluid
ones in JoinInlineAncestors().
Since ColumnSpanWrapperFrame can only have nsColumnSetFrame and
column-span wrappers kids, no need to perform bidi resolution. This
doesn't affect column contents because they'll inherit "unicode-bidi"
from ColumnSetWrapperFrame in ua.css.
Differential Revision: https://phabricator.services.mozilla.com/D17550
--HG--
extra : moz-landing-system : lando
ColumnSetFrame is always created by
nsCSSFrameConstructor::BeginBuildingColumns(). We search for it in the
possible child lists of ColumnSetWrapperFrame and its continuations.
Differential Revision: https://phabricator.services.mozilla.com/D14501
--HG--
extra : moz-landing-system : lando
The main style of <table> is set on the inner TableFrame, not the outer
TableWrapperFrame. Thus, we fail to spot the table as a column-span kid
in nsCSSFrameConstructor::ConstructionBlock().
Differential Revision: https://phabricator.services.mozilla.com/D13957
--HG--
extra : moz-landing-system : lando
I'm also adding the non-"inlines" version of the added "inlines" includes, too,
since it's nice to have them included as a pair. (It's not strictly necessary,
since in these cases we were already indirectly including the non-"inlines"
header, but it seems like a good practice.)
This patch fixes build warnings in non-unified builds for the following calls:
- The call to IsColumnSpan() in layout/generic/ColumnSetWrapperFrame.cpp
- The call to Type() in layout/style/MappedDeclarations.cpp
- The call to IsInAnonymousSubtree() in layout/svg/SVGObserverUtils.cpp
Differential Revision: https://phabricator.services.mozilla.com/D13743
--HG--
extra : moz-landing-system : lando
The assert is testing that the content's primary frame shouldn't
generate any native anonymous children, but what we really want to
ensure is that :-moz-column-span-wrapper doesn't create any native
anonymous child (because we don't restyle the wrapper), not the content
which creates ::-moz-column-span-wrapper. The condition is already
guaranteed by !aFrame->HasAnyStateBits(NS_FRAME_OWNS_ANON_BOXES) above.
Also, at this point during the frame construction, we haven't associate
the content with the its primary frame. Therefore,
nsContentUtils::AppendNativeAnonymousChildren() won't return anything
except for scrollbars on root element. That's why we have the crash in
this bug.
Differential Revision: https://phabricator.services.mozilla.com/D12359
--HG--
extra : moz-landing-system : lando
The major change in this patch is ::-moz-column-span-wrapper blocks are no
longer linked into the continuation chains when they're created in
CreateColumnSpanSiblings(). We can do that because
::-moz-column-span-wrapper is an non-inheriting anon box, which doesn't need
to be restyled.
This prevents RestyleManager::ProcessPostTraversal or
nsIFrame::UpdateStyleOfOwnedChildFrame, which set the same style on all
continuations of the frame they are working with, from overriding the
::-moz-column-span-wrapper style.
GetNextContinuationWithSameStyle was deleted in bug 1447367. Delete the comment
in nsInlineFrame::UpdateStyleOfOwnedAnonBoxesForIBSplit() to avoid confusion.
This patch also adds another condition to reframe the multi-column container
in MaybeRecreateContainerForFrameRemoval(). That condition is when an
element has a "column-span:all" descendant, i.e. the element's frame has
"column-span:all" siblings (which is created by CreateColumnSpanSiblings).
The added test multicol-span-all-dynamic-remove-006.html will fail without
this patch.
Depends on D5212
Differential Revision: https://phabricator.services.mozilla.com/D9988
--HG--
extra : moz-landing-system : lando
Other frames calling InitAndWrapInColumnSetFrameIfNeeded() needs to be
modified to support column-span (bug 1489295).
Depends on D5208
Differential Revision: https://phabricator.services.mozilla.com/D5209
--HG--
extra : moz-landing-system : lando
ColumnSetWrapperFrame is needed to implement column-span. Patches in bug
1421105 will utilize this frame.
Co-authored-by: Neerja Pancholi <npancholi@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D5092
--HG--
extra : moz-landing-system : lando