There's been a clarification to the spec text that this comment was worried about:
https://github.com/w3c/csswg-drafts/issues/2316
And with that clarification, this comment is no longer applicable.
This patch should not affect behavior.
Logic-wise: the idea behind this patch is to behave as if the
'usingFlexBasisForHeight' variable were always false, which in turn lets us
remove an "if (!usingFlexBasisForHeight || ...)" check, because it trivially
passes when that bool is false.
Background on this special case & why we can remove it:
=======================================================
In the original flexbox implementation, we had some special-case code to be
sure we didn't end up swapping in e.g. "flex-basis:-moz-min-content" for
"height" in these ComputeSize functions, because that was a scenario that
previously would've been prevented at the parser level (height:-moz-min-content
is rejected for now), and hence may not have ended up being handled robustly.
However, nowadays it'll be handled just fine in these functions, and will
produce the same result as our special-case exception tries to achieve.
In particular, for a nsFrame that is a flex item in a flex container with a
vertical main axis (the scenario that these special cases are catching):
- If the (vertical) main axis is this nsFrame's inline axis (i.e. if this
nsFrame has a vertical writing-mode), then Stylo actually converts
enumerated flex-basis values like "-moz-min-content" to "auto" when
producing the computed values that layout sees. So it's not actually
possible for layout to see a computed "flex-basis" of -moz-min-content, in
that scenario.
- Otherwise, i.e. if the (vertical) main axis is this nsFrame's block axis,
then these ComputeSize functions will now end up getting an enumerated
"blockStyleCoord" (really pointing to flexBasis), but that'll still end up
being treated like 'auto'. This happens by virtue of ComputeSize's calls to
ComputeAutoSize (which initializes the tentative bsize value to
NS_UNCONSTRAINEDSIZE) and to nsLayoutUtils::IsAutoBSize (which returns
"true" for eStyleUnit_Enumerated values and then makes us leave the
ComputeAutoSize result unperturbed).
The dirty bit fiddling is nontrivial, but it's pretty much what we do for
invalidation and allows to keep this incrementally easily.
The only caller that we cared about for the GetFlattenedTreeParent check in
DestroyFramesForAndRestyle was the old ShadowRoot invalidation functions that
went away.
MozReview-Commit-ID: GmgPPJ6d2qX
This was useful because nsRuleData in the old style system may not hold
all the data, but the only subclass ServoSpecifiedValues is always able
to hold any data, and thus passes NS_STYLE_INHERIT_MASK to mSIDS. Given
this, this method and mSIDs seems to be useless and can be removed.
MozReview-Commit-ID: 4vWcV4DRS2i
--HG--
extra : rebase_source : 4f364d431821e29838082e391c6dde08af7f5343
I don't have a strong preference about blending with white vs. just doing alpha
0.5, so I kept doing what we were doing, since Blink and WebKit also apply the
blending to the text background, and I'm not sure that's particularly desirable.
MozReview-Commit-ID: AwYtAgdlcxj
NullPrincipal::Create() (will null OA) may cause an OriginAttributes bypass.
We change Create() so OriginAttributes is no longer optional, and rename
Create() with no arguments to make it more explicit about what the caller is doing.
MozReview-Commit-ID: 7DQGlgh1tgJ
