This makes background-image, mask-image and border-image settable
from Servo.
Since imgRequestProxy resolution in nsStyleImages can now happen later than
at computed value setting time, and that resolution can fail,
nsStyleImage::GetImageData() might now return null. So all of the users of
nsStyleImage now null check its result.
MozReview-Commit-ID: FMRUrC3SfOs
This makes background-image, mask-image and border-image settable
from Servo.
Since imgRequestProxy resolution in nsStyleImages can now happen later than
at computed value setting time, and that resolution can fail,
nsStyleImage::GetImageData() might now return null. So all of the users of
nsStyleImage now null check its result.
MozReview-Commit-ID: FMRUrC3SfOs
Right now, there's only one flag in this new class (with no usages until a
later patch). This flag suppresses a hack, which otherwise makes us
transparently reverse the child list & flex axes in some circumstances, to
prevent bottom-to-top child ordering. (We don't want that hack when we're
dealing with individual abspos children, since it only makes things more
complicated.)
MozReview-Commit-ID: HYUf0vjlfiJ
Right now, this method has only one stub impl, in nsContainerFrame; a later
patch will add a more interesting (overriding) impl in nsFlexContainerFrame.
MozReview-Commit-ID: 3U3vTTX4vdm
This patch also:
* Removes some now-unnecessary code from nsFlexContainerFrame, which was for jumping from wrapped-placeholders to their out-of-flow frames (for DOM comparisons). This code is now unnecessary because placeholders won't be wrapped anymore.
* Updates some reftests with abspos content to match the updated spec's expectations, with one marked as "fails" for the time being (until bug 1269046 implements css box alignment, which we need to render that test correctly).
MozReview-Commit-ID: 8canWfXk6Kf
This patch makes the following specific changes:
(1) Adds an early-return to both versions of the IsOrderLEQ function, to treat placeholder children as LEQ everything (including each other). This will tend to sort them to the beginning of the child list, which is unimportant but fine. More importantly, though: this means our "order"-sorting code won't reorder placeholders *with respect to each other* (since our sort algorithm is stable). So their painting order won't be affected by the "order" property, which is required by the spec.
(2) Drops some nsPlaceholderFrame::GetRealFrameFor() calls -- they're unnecessary, since any placeholder frames will have prompted us to return earlier.
One caveat to (2): this patch does leave a few "nsPlaceholderFrame::GetRealFrameFor()" calls in place, *for the moment*. These remaining calls are for handling placeholders that are wrapped, i.e. inside of anonymous flex items. These calls are still needed to avoid assertion-failures (i.e. to get a consistent ordering) at this point, but they'll be removed in a later patch in this same bug, when we stop wrapping placeholders in anonymous flex items.
MozReview-Commit-ID: 1R6NW30Kxgv
This patch adds a pref to control whether we dispatch the selection
events for changes in the contents of input and textarea text controls.
The spec for this feature hasn't been written yet, and we need to exclude
this part of the selection API from the part we want to ship.
If, within a single refresh driver tick, the scroll position is updated by JS
explicitly, and then subsequently also updated by a frame reconstruction, the
scroll origin from the former (nsGkAtoms::other) can get clobbered by the latter
(to nsGkAtoms::restore). The restore scroll origin is "weaker" in that it can
be ignored by the APZ code in some circumstances. This is undesirable because
it means the JS scroll update also gets ignored. This patch ensures that when
setting the scroll origin we don't do this clobbering of stronger origins with
weaker origins.
MozReview-Commit-ID: DA4EHp1Debu
--HG--
extra : rebase_source : 99fd1f91698a605792b2a622450f1ff31bc89101
The spec says that single-line flex containers should stretch their one flex
line to the flex container's cross size, and should ignore 'align-content'.
Initially, the spec defined 'single-line' to include any flex container that
happens to have only 1 line (even if it's got 'flex-wrap:wrap' or
'wrap-reverse'). But later, the term 'single-line' was intentionally redefined
to *only* include flex containers that have 'flex-wrap: nowrap'. So, instead
of checking the line-count, we should instead check 'flex-wrap', when deciding
whether to stretch our one line & ignore 'align-content'.
MozReview-Commit-ID: D2ZMIBS16ui
--HG--
extra : rebase_source : 835a64e0f9cdaa375f8e57f55ffe5b011525cbeb
The spec says that single-line flex containers should stretch their one flex
line to the flex container's cross size, and should ignore 'align-content'.
Initially, the spec defined 'single-line' to include any flex container that
happens to have only 1 line (even if it's got 'flex-wrap:wrap' or
'wrap-reverse'). But later, the term 'single-line' was intentionally redefined
to *only* include flex containers that have 'flex-wrap: nowrap'. So, instead
of checking the line-count, we should instead check 'flex-wrap', when deciding
whether to stretch our one line & ignore 'align-content'.
MozReview-Commit-ID: D2ZMIBS16ui
--HG--
extra : rebase_source : c600a80b96df3c937f2a56a5e0ed1825750234e0
Mats Palmgren
Cameron McCormack
Daniel Holbert
Phil Ringnalda
Markus Stange
Xidorn Quan
Carsten "Tomcat" Book
Jorg K
Brad Werth
Botond Ballo
Ehsan Akhgari
L. David Baron
Michael Layzell
Julian Descottes
Kartikaya Gupta
Wes Kocher
cku