To be clear, this is a "paving the way" patch. At this point in the patch
series, it's not yet possible for us to generate a nsFlexContainerFrame that
has display:-moz-box. (A later patch in this series will make that possible.)
This patch adds the mechanics to nsFlexContainerFrame instances so that they'll
label themselves appropriately (with NS_STATE_FLEX_IS_EMULATING_LEGACY_BOX)
once it *does* become possible for -moz-box to spawn a nsFlexContainerFrame.
Moreover, this patch updates the state bit's documentation to reflect its new
potential-usage.
MozReview-Commit-ID: ElApieVoTLf
This patch isn't changing semantics of this bit at all - it just renames it to
a more general name. In other words, this patch does not change behavior.
MozReview-Commit-ID: 4wb13X4YinJ
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
If a frame doesn't have that bit then skip mCounterManager.DestroyNodesFor()
when the frame is destroyed because it's definitely not known by
the CounterManager.
MozReview-Commit-ID: Ky3575QvZME
This patch is just flipping some logic in a way that should produce the same
outcome, so it shouldn't affect behavior.
MozReview-Commit-ID: LM4HbJD3D9w
This protects all accesses to the frame property table with a bit stored
on the frame. This means we avoid hashtable operations when asking
about frame properties on frames that have no properties.
The changes to RestyleManager, and the new HasSkippingBitCheck API, are
needed because RestyleManager depended on being able to ask for
properties on a deleted frame (knowing that the property in question
could not have been set on any new frames since the deleted frame was
destroyed), in order to use the destruction of the properties that
happens at frame destruction as a mechanism for learning that the frame
was destroyed. The changes there preserve the use of that mechanism,
although it becomes a bit uglier. The ugliness is well-deserved.
MozReview-Commit-ID: BScmDUlWq65
This protects all accesses to the frame property table with a bit stored
on the frame. This means we avoid hashtable operations when asking
about frame properties on frames that have no properties.
The changes to RestyleManager, and the new HasSkippingBitCheck API, are
needed because RestyleManager depended on being able to ask for
properties on a deleted frame (knowing that the property in question
could not have been set on any new frames since the deleted frame was
destroyed), in order to use the destruction of the properties that
happens at frame destruction as a mechanism for learning that the frame
was destroyed. The changes there preserve the use of that mechanism,
although it becomes a bit uglier. The ugliness is well-deserved.
MozReview-Commit-ID: BScmDUlWq65
