Open Bug 1143302 Opened 7 years ago Updated 7 years ago

fix the handling of mOriginalDisplay in nsStyleContext::ApplyStyleFixups

Categories

(Core :: CSS Parsing and Computation, defect)

defect
Not set
normal

Tracking

()

People

(Reporter: jfkthame, Unassigned)

Details

Copied from bug 1134849 comment 3 (:dbaron), referring to nsStyleContext::ApplyStyleFixups():

> Comment on attachment 8576547 [details] [diff] [review]
> For display:inline elements whose writing mode is orthogonal to their
> parent's, the computed value should become inline-block
> 
> This isn't quite right, because you should also be correcting
> disp->mOriginalDisplay when it is NS_STYLE_DISPLAY_INLINE and mDisplay is
> not, given that:
> http://dev.w3.org/csswg/css2/visudet.html#abs-non-replaced-width says:
> 
>   The static-position containing block is the containing block of a
> hypothetical box that would have been the first box of the element if its
> specified 'position' value had been 'static' and its specified 'float' had
> been 'none'. (Note that due to the rules in section 9.7 this hypothetical
> calculation might require also assuming a different computed value for
> 'display'.) 
> 
> which is part of what mOriginalDisplay is for.
> 
> The other part of what mOriginalDisplay is for (and all of what
> mOriginalFloats is for) is doing correct computation when we start
> computation based on a cached struct in the rule tree (an aStartStruct
> parameter to nsRuleNode::Compute*Data); that's not relevant here since the
> GetUniqueStyleData means the data are cached on the style context and not
> the rule tree.  See bug 608756.
> 
> (I think you can assert that if mOriginalDisplay is not inline, then
> mDisplay is also not inline, so the initial test should be able to test only
> mOriginalDisplay.)
> 
> 
> There should probably be a comment explaining this (like the comment above
> in the same function where we do the display fixups for the root).
> 
> 
> It also seems like the root fixup, the flex/grid fixup, and the ruby fixup
> might be wrong in a similar way (although the latter two are not touching
> mOriginalDisplay at all, which I think they should be), although I didn't
> look that closely.
You need to log in before you can comment on or make changes to this bug.