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
--HG--
extra : rebase_source : 0c59e2a0adc8e060a687e5ffdf6246eb8068eef6
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
--HG--
extra : rebase_source : 9a89ce8782f735d7f4a8ad471606a2af5201ac83
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
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
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
--HG--
extra : transplant_source : %C8%C0%CD%DC%12g%5B%8ER%3A%FF%A7a%F8%91%D4%2C%9BF%2B
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
--HG--
extra : transplant_source : %95%A2%9B%A1M%1F%86%A8%E0%FF%7B%E4%83%24%83%16%BE%FA%08T
I also adjust some of the old flag name to their logical name, and
rewrite some of the content where I see fit.
MozReview-Commit-ID: 7wAsDUOiN0a
--HG--
extra : rebase_source : 18e28e5ed1c593fb272042508b36244f132da4f5
We're keeping the core idea that, before we remove the frames-to-be-destroyed
from the continuation chain, their textruns need to be disconnected/destroyed.
However, nsContinuingTextFrame::DestroyFrom tries to optimize when the
destroying frames that aren't mentioned in the userdata for the textrun, and
certain other conditions are met; we need a similar optimization here. It's
simpler here because the other conditions are definitely met, since all the
text for the frames being deleted has already been consumed and reflowed by
previous frames.
We don't need the TEXT_STYLE_MATCHES_PREV_CONTINUATION state bit anymore
because nsContinuingTextFrame::DestroyFrom will never see any textruns when
called via RemoveEmptyInFlows.
--HG--
extra : rebase_source : 6544f923499ef604d48ec15961716549dd25d279
Daniel Holbert
Brad Werth
Phil Ringnalda
Matt Woodrow
Jonathan Watt
Mats Palmgren
Jonathan Kew
Thinker K.F. Li
L. David Baron
Boris Zbarsky
Ting-Yu Lin
Kearwood (Kip) Gilbert
Ting-Yu Lin
Carsten "Tomcat" Book
Seth Fowler
Kartikaya Gupta
Xidorn Quan
Robert O'Callahan
Wes Kocher
Vladimir Vukicevic
Markus Stange