Many of the modifications are guarded by #ifdefs. I verify them locally
by manually define them in nsBlockDebugFlags.h and nsLinelayout.cpp.
Note that I replace "mFrame" with "frame" in lines guarded by
NOISY_BLOCK_DIR_MARGINS in nsBlockFrame.cpp because they were
incorrectly renamed in Bug 1277129 Part 6a.
https://hg.mozilla.org/mozilla-central/rev/a70b04f074fc
Differential Revision: https://phabricator.services.mozilla.com/D17733
The crash happens when we try to reparent the absolute/fixed
positioned children to the non-column-span wrapper's absolute list.
When constructing the multicol container, we want it to be the
absolute/fixed position container, not the moz-column-content anonymous
blocks. Hence the modification in AppendFramesToParent() and
ConstructBlock().
Delete AdjustAbsoluteContainingBlock() because we'd like to reparent
absolute/fixed children to non-first continuation of block descendant of
multicol. And it doesn't crash anymore today.
Differential Revision: https://phabricator.services.mozilla.com/D16728
Move CaptureStateForFramesOf into ContentRemoved, so we can traverse frames
which were under display: contents as well.
Differential Revision: https://phabricator.services.mozilla.com/D15319
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
There's no real behavior change, since:
* aFlags right now is only used for whitespace suppression optimizations (which
we don't do when display: contents is involved anyway).
* The CouldBeDisplayContents() check is only an optimization: we're
unconditionally recursing into ContentRemoved now, which is not incorrect,
just inefficient.
I found this while reviewing https://phabricator.services.mozilla.com/D15319
(where this _would_ have an impact on behavior).
Differential Revision: https://phabricator.services.mozilla.com/D15373
The elements under <body> are treat as content append, so their frames
will be construct by nsCSSFrameConstructor::ContentAppended.
This patch fixed only the simple "append" case which is appending to the
last continuation of ::moz-column-content. For other more complex
appending or inserting cases, we might need to reframe (bug 1504053).
Differential Revision: https://phabricator.services.mozilla.com/D16076
To reproduce, execute
"GECKO_FRAMECTOR_DEBUG_FLAGS=really-noisy-content-updates ./mach run".
nsIFrame::List()'s second argument should be a const char*, not an
integer. We can fix the bug by omitting it because the default value of
the argument is an empty string.
Differential Revision: https://phabricator.services.mozilla.com/D16075
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
GetParent() already returns nsContainerFrame*, and it's easier to use
with API like FinishBuildingColumns() demanding a nsContainerFrame*.
Differential Revision: https://phabricator.services.mozilla.com/D15549
This is to prevent Part 1 from breaking
testing/web-platform/tests/css/css-multicol/multicol-span-all-restyle-002.html
After introducing Part 1, we now use CreateContinuingFrame() to create
non-column-span wrapper frames, which use nsFrame::Init() rather than
InitAndRestoreFrame() to initialize them. Because the bits in
aState.mAdditionalStateBits are added to frames only when
nsCSSFrameConstructor::InitAndRestoreFrame() is called. We need a new
way to add the NS_FRAME_PART_OF_IBSPLIT to non-column-span wrapper
frames.
Note that we used to add NS_FRAME_PART_OF_IBSPLIT to both column-span
wrapper and non-column-span wrapper. After this patch, column-span
wrapper won't have NS_FRAME_PART_OF_IBSPLIT. That's fine because
column-span wrappers are not linked with other frames and they
shouldn't get this bit set.
Depends on D15134
Differential Revision: https://phabricator.services.mozilla.com/D15452
In CreateColumnSpanSiblings(), aInitialBlock can be a DetailsFrame.
Therefore, when creating a non-column-span wrapper, we cannot assume
it's always a block frame. We need to use CreateContinuingFrame to
ensure the correct type of continuation is created.
Differential Revision: https://phabricator.services.mozilla.com/D15134
If a ColumnSetWrapperFrame already has column-span children,
ColumnSetWrapperFrame::GetContentInsertionFrame() will return itself to
let WipeContainingBlock() aware this is the case to reframe.
To make this work, we need to move the reframe condition prior to check
NS_FRAME_HAS_MULTI_COLUMN_ANCESTOR bit because the top level
ColumnSetWrapperFrame never has NS_FRAME_HAS_MULTI_COLUMN_ANCESTOR bit
set.
Differential Revision: https://phabricator.services.mozilla.com/D14819
Bug 1506163 fixed only part of the issue. There are more types of frames
such as table, grid, flex, etc. that create their own block formatting
context.
Instead of propagating NS_FRAME_HAS_MULTI_COLUMN_ANCESTOR to the
children, we explicit carry the bit over to block and inline frames by
checking that their parent doesn't suppress column-span descendants.
Also, remove the unused "onload" from <body> in the tests.
Differential Revision: https://phabricator.services.mozilla.com/D13597
This patch moves all UA Widget calls to helper functions in Element.cpp. The helper function AttachAndSetUAShadowRoot sets the shadow root in a runnable, so that it is in the same order of NotifyUAWidget* runnables.
Differential Revision: https://phabricator.services.mozilla.com/D13479
All of the removed includes are redundant (i.e. they're #included elsewhere in
the same file).
In most cases, I'm removing the second (redundant) copy of the
#include, except when that copy makes more sense (i.e. if it's in better sorted
order, or if it's paired alongside a closely-associated header while the
earlier copy is not).
Here's the script that I used to generate candidates here -- I ran this in
every subdirectory of layout, on my linux machine (warning, this writes two
files to your /tmp directory):
for FILE in *.h *.cpp; do
nonunique=$(grep \#include $FILE | grep -v List\.h | cut -f2 -d'"' | cut -f2- -d'/'| cut -f2- -d'/' | sort | wc -l)
unique=$( grep \#include $FILE | grep -v List\.h | cut -f2 -d'"' | cut -f2- -d'/'| cut -f2- -d'/' | sort | uniq | wc -l)
if [[ "$unique" != "$nonunique" ]]; then
echo "$FILE: $nonunique / $unique"
grep \#include $FILE | cut -f2 -d'"' | grep -v List\.h | cut -f2- -d'/'| cut -f2- -d'/' | sort > /tmp/nonunique.txt
grep \#include $FILE | cut -f2 -d'"' | grep -v List\.h | cut -f2- -d'/'| cut -f2- -d'/' | sort | uniq > /tmp/unique.txt
diff /tmp/nonunique.txt /tmp/unique.txt
echo
fi
done
Depends on D13773
Differential Revision: https://phabricator.services.mozilla.com/D13774
The example frame tree didn't survive the global clang-format change.
DONTBUILD because this is a comment-only change.
Differential Revision: https://phabricator.services.mozilla.com/D13602
This changes the logic from !IsInlineOutside() to IsBlockOutside()
so that table-internal display types etc are now excluded
(i.e. no longer creates an ib-split).
This patch also gives nsCSSFrameConstructor.h its own UniquePtr include (since
we have some UniquePtr usage there, but no include). Presumably it's already
getting the include indirectly (via some other header) right now, but it should
really include it directly if it uses the type directly.
(This leaves one nsAutoPtr usage in nsCSSFrameConstructor, for 'mNode'. We can
probably convert that one without too much trouble, but I'm not doing so yet,
in part because we intentionally leak that variable in one spot and I haven't
fully worked out the ownership transfer for that case.)
Differential Revision: https://phabricator.services.mozilla.com/D12992
The other uses of isFlexOrGridContainer were removed in
https://hg.mozilla.org/mozilla-central/rev/fa81899efb5e
We can rely on ShouldSuppressFloatingOfDescendants() to look
IsFlexOrGridContainer() up.
Also, move ::IsFlexOrGridContainer() to be the first condition to check in
ShouldSuppressFloatingOfDescendants() since it should be a more common use
case than the others.
Differential Revision: https://phabricator.services.mozilla.com/D12609
When removing an out of flow frame under a multicol subtree, it shouldn't affect
the multicol tree structure. We should instead check the in flow frame's
relationship with the multicol subtree.
Differential Revision: https://phabricator.services.mozilla.com/D11540
The modification to nsLayoutUtils::GetFirstLinePosition() is needed because we
need to get the correct first line position from child (i.e. ColumnSet) when
there's an outside bullet on ColumnSetWrapperFrame.
The difference between the two newly added tests is "overflow: hidden" on
the columns.
Differential Revision: https://phabricator.services.mozilla.com/D7009
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
