The test case triggers MOZ_ASSERT(!IsFramePartOfIBSplit(aParentFrame))
in MaybeRecreateForColumnSpan() because WipeContainingBlock() returns
early when the FrameConstructionItemList is empty. Thus, it doesn't wipe
the aParentFrame even if it's part of an IB split.
An empty FrameConstructionItemList constructs no frames. Therefore,
MaybeRecreateForColumnSpan() doesn't need to do anything if aFrameList is empty
since an empty frame list cannot contain any column-span.
Differential Revision: https://phabricator.services.mozilla.com/D23820
The assertion can be reproduced locally by running
"./mach test dom/canvas/test/chrome/test_drawWindow_widget_layers.html"
with layout.accessiblecaret.enabled=true.
When AccessibleCaret is enabled, caret elements will be inserted into
nsCanvasFrame::mCustomContentContainer, thus it recursively invokes
ConstructFramesFromItemList() to construct frames for carets before it had a
chance to construct popup group.
I feel it's too strict to assume that ConstructFramesFromItemList() cannot be
invoke recursively whenever there's a popup group item. I move the assertion to
the end of ConstructDocElementFrame() to ensure the popup group is processed by
then.
Differential Revision: https://phabricator.services.mozilla.com/D10298
aFrameList can contain placeholder frames. If we decide to nuke
aFrameList, we need to destroy the out-of-flow frames gracefully.
In this case, out-of-flow frames are still in nsFrameConstructorState's
absolute item lists. To rely on nsPlaceholderFrame::DestroyFrom() to
remove its out-of-flow frame properly, we manually flush all the frame
insertions for all the lists in aState before destroying aFrameList.
Differential Revision: https://phabricator.services.mozilla.com/D19460
This is more consistent with what the Rust bits of the style system do, and
removes a pointer from ComputedStyle which is always nice.
This also aligns the Rust bits with the C++ bits re. not treating xul pseudos as
anonymous boxes. See the comment in nsTreeStyleCache.cpp regarding those.
Can't wait for XUL trees to die.
Depends on D19001
Differential Revision: https://phabricator.services.mozilla.com/D19002
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
