This changeset is intended to revert the logic from "Bug 1269045 part 3" [1],
*specifically* for legacy "-webkit-box"/"-webkit-inline-box" flex containers.
[1] https://hg.mozilla.org/mozilla-central/rev/707b2ab5879d
MozReview-Commit-ID: vc4TuAoLai
This patch doesn't affect behavior at all -- it just refactors the
sanity-checking function "FrameWantsToBeInAnonymousItem()", so that the next
patch in this series can give it a new special case that checks a state bit on
the container frame.
This patch renames "parent" to "container" in this function's variable-names,
for clarity, because when this function returns true, the flex/grid container
is actually NOT expected to be the parent of aFrame. Rather, it's expected to
be the grandparent, and the anonymous flex/grid item would be the parent. So,
"aContainerFrame"/"containerType" is a bit more accurate (representing the
flex/grid container for aFrame).
Also worth mentioning: this patch makes FrameWantsToBeInAnonymousItem() perform
its own local GetType() call, instead of accepting an already-queried GetType()
result from the caller (as it previously did). Technically this could cause a
slight perf hit, but it doesn't really matter since this is in "#ifdef DEBUG"
sanity-checking code anyway. We could keep the nsIAtom* as an additional arg
to avoid this new call, but it seems better to fall on the side of simplicity &
just look up GetType() independently, rather than complicating the function
signature with an extra arg.
MozReview-Commit-ID: 4oJFkQMuH9c
I noticed that our current behavior in ContentRangeInserted is incorrect. Unlike
ContentInserted (where this code lived originally), ContentRangeInserted takes a
start and end element. I'm not sure if we ever take that path for new content that
needs style, but it seemed sketchy. And generally, it seems nice to just always
style new content the same way (though we still need to style NAC by the subtree
root, since it hasn't been attached to the parent yet).
For situations where there is indeed only one unstyled child, the traversal
overhead should be neglible, since we special-case the single-element in
parallel.rs to avoid calling into rayon.
Being more explicit about what we want here also makes us more robust against
the other handful of callpaths that can take us into
nsCSSFrameConstructor::{ContentRangeInserted,ContentAppended}. Currently we
can call StyleNewSubtree on an already-styled element via RecreateFramesForContent,
which triggers an assertion in the servo traversal.
MozReview-Commit-ID: DqCGh90deHH
Note that at the callsites in nsCSSFrameConstructor.cpp, we have to also check
the frame type (since the frame state bit is in a range of bits whose meaning
differs depending on frame type). The first change in this patch is the
addition of a convenience fucntion that checks both the frame type as well as
the frame state bit.
MozReview-Commit-ID: DEOThTX5NAO
Bug 1259889 Part 2 [1] cannot be reverted cleanly, so I manually undo those
changes in this patch. That is, remove the ability for html.css to
invalidate dynamically since it was added specifically for details element.
Although reftest-stylo.list explicit mentions "DO NOT EDIT!", but I still
remove details pref from the file, since it doesn't harm to edit it anyway.
[1] https://hg.mozilla.org/mozilla-central/rev/30aaf3805b56
MozReview-Commit-ID: FsyTGQTxujh
This patch also:
* Removes some now-unnecessary code from nsFlexContainerFrame, which was for jumping from wrapped-placeholders to their out-of-flow frames (for DOM comparisons). This code is now unnecessary because placeholders won't be wrapped anymore.
* Updates some reftests with abspos content to match the updated spec's expectations, with one marked as "fails" for the time being (until bug 1269046 implements css box alignment, which we need to render that test correctly).
MozReview-Commit-ID: 8canWfXk6Kf
The major change to the Iterator is due to the fact that the end of a
LinkedList is represented by nullptr.
Also delete the type conversion functions which are no longer needed.
MozReview-Commit-ID: 2lYtFW9pSon
Change the logic that moves the main summary to the front from operating
on generated frames in DetailsFrame::SetInitialChildList() to operating
on frame construction item list in AddFrameConstructionItemsInternal()
so that it will be correct when cooperating with ::first-line.
The root cause of the bug reported is because when specifying
::first-line on details element, the first frame of summary element,
which is generated due to ib-split, will be wrapped in nsFirstLineFrame.
The original code fails to find the summary frame in the wrapper frame
and triggers assertion because of the second ib-split summary frame. To
fix that, we need to descend into the child list of wrapper frames when
checking the main summary.
Add original test case as a crashtest as well as reftests to clearly
reproduce the issue.
Note that in the reftest, the blue color in ::first-line is applied
incorrectly to the second line in the summary due to bug 520605.
MozReview-Commit-ID: Bv4Vcvxp6pY
SummaryFrame had been removed in bug 1258657, so now HTMLSummaryElement
is always rendered as an ordinary inline or block frame. Therefore, the
check in FindHTMLData is not needed anymore.
MozReview-Commit-ID: Ikxla6QoNLT
