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
See bug 1422633, there are assertions missing, and servo doesn't assert at all
anymore.
I don't think it's worth optimizing / lazily resolving it, each time the
document state changes.
We usually just restyle the world anyway (which requires recomputing it), and
the changes that it's optimizing (nsWindow::SetActive() and XUL root element
localedir attribute changes) aren't common enough to warrant the complexity I'd
say.
This doesn't handle invalidating the cache in the case the root element goes
away, I haven't bothered because it was already broken, and GetRootElement() is
already gone in RemoveSubtreeFromDocument.
MozReview-Commit-ID: 9RuQhmmy7Kr
Prior to bug 1368776, when no surface was obtained for the container, no
container was returned. Since we prefer an empty image container with
WebRender to avoid fallback, this was changed, but regressed
non-WebRender behaviour. Now on the non-WebRender path, we check if
there is anything in the container before accepting it.
