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
--HG--
extra : rebase_source : 3cc143055fc46851e882d48df2bd913ca1487793
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
--HG--
extra : rebase_source : 3b5d60d8c15e69470f450168698b855e353486d3
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
--HG--
extra : rebase_source : 95e86eec663b3ef2e7bb86214871fcd3ea86057c
The class PresShell doesn't have ns-prefix, so it's better to drop ns-prefix
in the file names to avoid confusion.
MozReview-Commit-ID: IljxsF5CVjh
--HG--
rename : layout/base/nsPresShell.cpp => layout/base/PresShell.cpp
rename : layout/base/nsPresShell.h => layout/base/PresShell.h
extra : rebase_source : e73a6873f360a7223d87bd22d9854fc9603c499f
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
--HG--
extra : rebase_source : 25e5a05a8a5a47642772da69f427631fa07e232d
