Now that accessing nsIContent slots is not a blob of virtual function calls, we
should be able to unify logic here, and speed up the not-so-rare case for
chrome, while keeping the usual case fast.
MozReview-Commit-ID: 87iY5Cbhx4T
This matches Blink's behavior.
Just skipping table row groups from being containing blocks makes
layout/reftests/table-overflow/table-cell-block-overflow.html render differently
(and way more different than any other browser, actually...), so I avoided doing
that.
Though I'm not really proud of this one, better ideas welcome. Maybe I should
just fix table layout so that we agree with WebKit / Blink... But that seemed
harder, too.
MozReview-Commit-ID: AkUB4MFzwZK
This test case is broken. The anchor element is drag but not canvas element. Shift the position of mousedown event a little bit so that the canvas element is drag.
MozReview-Commit-ID: 5Ebqtbzwg0d
ShapeInfo and its derived classes are private to nsFloatManager, which don't
need to be in the header. Move them to cpp to make compile faster after
changing them.
MozReview-Commit-ID: MRkBGoqcPj
--HG--
extra : rebase_source : bc1de4269629f881e49af0d4faba89e8fbd4e460
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
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
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.
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.
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