The failure mode in the attached crashtest is an inconsistency in the flattened
tree. Specifically, we null out mVideoControls in an nsVideoFrame, but defer
the UnbindFromTree call on that NAC element, which measn that its mParent still
points to the nsVideoFrame's mContent. Because all this stuff runs off of script
runners, and the anonymous content destroyer is not guaranteed to run before
other potential script runners, we end up running arbitrary script while the
tree mismatch exists. This script calls back into ProcessPendingRestyles, which
causes trouble.
We could build a separate deferral mechanism, but it's not clear that we actually
need to defer the unbind anymore. The deferred unbind was added in bug 489008,
which predated a lot of simplifications in layout/dom interaction.
MozReview-Commit-ID: 1JYAhiXKVJC
We have four entry points that deal with the parents of display:none/
display:contents content. These are the functions for setting, changing,
getting and removing a style context. Or more specifically:
GetUndisplayedNodeInMapFor
called by GetDisplay[None|Contents]StyleFor (via GetStyleContextInMap)
SetStyleContextInMap
called by RegisterDisplay[None|Contents]StyleFor
ChangeStyleContextInMap
called by ChangeRegisteredDisplay[None|Contents]StyleFor
UnregisterDisplay[None|Contents]StyleFor
okay, this is actually two functions, but they act as a pair
This change makes all these functions call GetApplicableParent up front and act
on and pass around the parent that it returns. This is so that throughout
the code we are always handling the parent that will be used as the key in
the UndisplayedMap entry. This is necessary so that all the code that
sets/gets the 'MayHaveChildrenWithLayoutBoxesDisabled' bit on/from an
nsIContent object is using the same object, otherwise everything breaks down.
MozReview-Commit-ID: 6gso1tyr33E
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
This is the second of two big chunks of code moved into the new
RestyleManager class from another sources.
Note that the undisplayed map remains in nsFrameManager, although it
could perhaps have moved.
This is needed for the following patch, which leaves the undisplayed map
in nsFrameManager rather than moving it to RestyleManager (I think one
could argue for either way, but it was easier not to move it).
This propagates the non-inherited (in the nsChangeHint sense, not the
CSS inheritance sense) parts of the parent's change hint through
ReResolveStyleContext so that we can use them in
nsStyleContext::CalcDifference. In the cases where we don't know the
parent's hint, we assume the worst, that all the non-inherited hints
were present in the parent's style change.
This should be a significant performance improvement handling simple
style changes (such as a style attribute change setting a non-inherited
property) on elements with large numbers of descendants that have data
in ForceCompare structs that can't be stored in the rule tree (for
example, margins or widths in em or rem units).
