Instead move UndisplayedNode to its own file, which is what causes the include
hell due to requiring nsIContent / nsStyleContext.
MozReview-Commit-ID: 1opiajueZNb
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
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
This patch shouldn't affect behavior -- it just takes a latent opportunity for
simplification and removes an unused layer of indirection. These functions were
set up to look like they took outparams, but none of the callers were using the
value left in the outparam.
MozReview-Commit-ID: LaL7YiyVYS2
nsFrameManager::CaptureFrameStateFor generates keys for stateful frames that
only take into account the document and element. This precluded saving pieces
of information coming from different frames responsible for the same element.
MozReview-Commit-ID: 29x3Gj66wAy
