This also removes some confusing comments around nsIDocument regarding some kind
of "special" stylesheets, which don't seem to exist anymore, and consolidates
StyleSheetList so that we only have one implementation.
I think that fixes a potential leak on the shadow root code (even though the API
is v0 only), given the pointer from the ShadowRootStyleSheetList to the
ShadowRoot wasn't being CCd.
Also, more stuff could be renamed, methods removed, etc, feel free to suggest
more cleanup, I've done mostly the minimal.
Next steps are moving the stylesets there and stop using the proto binding sheet
list / resources.
MozReview-Commit-ID: D9hnDgPQAS5
This also removes some confusing comments around nsIDocument regarding some kind
of "special" stylesheets, which don't seem to exist anymore, and consolidates
StyleSheetList so that we only have one implementation.
I think that fixes a potential leak on the shadow root code (even though the API
is v0 only), given the pointer from the ShadowRootStyleSheetList to the
ShadowRoot wasn't being CCd.
Also, more stuff could be renamed, methods removed, etc, feel free to suggest
more cleanup, I've done mostly the minimal.
Next steps are moving the stylesets there and stop using the proto binding sheet
list / resources.
MozReview-Commit-ID: D9hnDgPQAS5
--HG--
extra : rebase_source : 0597917521894288c6b749e5d3ac6ac3b7db44a0
This feature is intended to help Firefox frontend developers experiment with
replacing XUL content with modern flexbox. We might also eventually use
this emulation to *actually* render most or all of our legacy XUL UI.
MozReview-Commit-ID: 3g2W9o3t23H
--HG--
extra : rebase_source : a3e8b443d9b58e5af3287a23de6edc276ed5e847
In modern flexbox and in "display:-webkit-box", children with
"visibility:collapse" currently generate "struts" which have 0 main-size but
nonzero cross-size.
But XUL/-moz-box treats these children differently -- it makes them 0-sized in
both axes. So we need to add a custom behavior to modern flexbox in order to
emulate that.
Specifically, this patch makes us:
- Ignore these children when computing the flex container's intrinsic sizes.
- Take a simpler codepath with 0-sized struts for collapsed elements when
laying out a -moz-box (rather than the typical 2-pass layout, with strut
cross-size being established in the 1st pass).
MozReview-Commit-ID: IpkADpFFBMx
--HG--
extra : rebase_source : d42a291c414c61906a82c2be2b5f1834aa24e4e3
XUL popups (i.e. FrameConstructionItem instances with mIsPopup==true) behave
like out-of-flow content -- in particular, they generate nsPlaceholderFrame
instances. So, they need the same placeholder-wrapping behavior that we have
for other out-of-flow frames inside of an emulated legacy box, in order to
satisfy our existing invariants.
MozReview-Commit-ID: KnspN4kTPnx
--HG--
extra : rebase_source : 8487f4ee50b21dc0389514fe34a17a73375a58ab
This patch does not change behavior. This patch just refactors the logic in
IsXULDisplayType so that -moz-box and -moz-inline-box are handled via a
dedicated early-return. This lets a later patch in this series make a more
understandable targeted tweak to add pref-controlled behavior for these display
values.
MozReview-Commit-ID: 6keGrxJcA5l
--HG--
extra : rebase_source : a4c7a6dd205da7d7c39c172ebb6d0c3bb7cd5458
Now that (per previous patch) NS_STATE_FLEX_IS_EMULATING_LEGACY_BOX isn't just
a webkit-box-specific tag: this patch here generalizes the variable-names and
comments associated with that flag in nsCSSFrameConstructor.cpp.
This patch does not make any changes to behavior; it's simply renaming &
comment tweaks.
MozReview-Commit-ID: DcF5GirAQwD
--HG--
extra : rebase_source : d847c5579399a4cc31dc14a52a93b03ed917034e
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 breaks rendering when we try do a sync decode paint since we might not have created the nsDisplayImage/nsDisplayBackgroundImage yet (or cached the empty size) and so we never get to the actual paint call.
With webrender and gfx.webrender.hit-test enabled, we create
nsDisplayCompositorHitTestInfo items which are subclasses of nsDisplayEventReceiver,
and we do so even for painting display lists. So this assertion trips even though
this is the desired behaviour. I'm taking the assertion out as it is not really
needed.
DONTBUILD because trivial assertion removal
MozReview-Commit-ID: Bs9PjtQSwqQ
Perspective item indices (used to produce unique per-frame keys) were generated
by incrementing a counter in the builder when building a perspective display
item. This caused problems with retained display lists, because an unmodified
perspective could be skipped during a partial build, causing other perspectives
to be incorrectly numbered and then incorrectly merged with the previous
retained display list.
To fix this, we need to always increment the counter if there is likely to be
a perspective, before that item may be skipped.
MozReview-Commit-ID: Edn7lUOLuPw
--HG--
extra : rebase_source : 5d10d4595576d17a2ac3fa6d6289fb98408c3654
