1311208 - orthogonal block elements inside inline-block containers get too little inline space

Status: NEW

(Core :: Layout: Block and Inline, defect, P3)

Description

[Brad Werth [:bradwerth]]

Attachment: inline-block sideways testcase.html

The attached testcase shows a block element with writing-mode:sideways-lr inside an inline-block container. It appears to get almost no inline space, and the contents of the next inline-block container mostly overwrite the sideways element.

Additional buggy behavior: zoom up or down one step and the page will show an appropriate-sized box for the sideways element. Returning to 100% zoom retains the newly-shown box.

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Brad Werth [:bradwerth] from comment #0)
> Additional buggy behavior: zoom up or down one step and the page will show
> an appropriate-sized box for the sideways element. Returning to 100% zoom
> retains the newly-shown box.

That indicates that we're getting the layout wrong on the initial reflow, but we're getting things correct on (sufficiently-thorough) subsequent incremental reflows.

Comment 2

[Brad Werth [:bradwerth]]

(In reply to Daniel Holbert [:dholbert] from comment #1) 
> That indicates that we're getting the layout wrong on the initial reflow,
> but we're getting things correct on (sufficiently-thorough) subsequent
> incremental reflows.

The post-zoom layout may also be wrong -- there are strange effects in the size of the boxes at various zoom levels with different zoom step directions. You will get different-sized boxes when zooming 170% -> 200% than you will get 240% -> 200%, for example. Box sizes don't seem stable until zoom 240%.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 2: hover to change font-size

Here's another testcase which provides an extra way to trigger incremental reflows -- hovering. (which changes the font-size via a :hover CSS rule)

With this testcase, I can produce 3 distinct renderings, from steps that should all produce the same rendering:
 (1) "j" mostly covered up (this is the initial rendering)
 (2) "j" partly covered up (if I hover/unhover the foot of the "j")
 (3) "j" not covered at all (if I zoom and then unzoom)

Comment 4

[Jonathan Kew [:jfkthame]]

This isn't specific to sideways-lr; similar issues can be reproduced with any orthogonal writing mode, AFAICS.

I guess the original problem is that the orthogonal block hasn't set its block-size yet at the point where the enclosing container is computing its inline-size, so it ends up with zero. In the :hover case, I think there may also be issues where we don't always correctly track what needs to be reflowed across an orthogonal boundary.

Comment 5

[Jonathan Kew [:jfkthame]]

(In reply to Brad Werth [:bradwerth] from comment #2)
> (In reply to Daniel Holbert [:dholbert] from comment #1) 
> > That indicates that we're getting the layout wrong on the initial reflow,
> > but we're getting things correct on (sufficiently-thorough) subsequent
> > incremental reflows.
> 
> The post-zoom layout may also be wrong -- there are strange effects in the
> size of the boxes at various zoom levels with different zoom step
> directions. You will get different-sized boxes when zooming 170% -> 200%
> than you will get 240% -> 200%, for example. Box sizes don't seem stable
> until zoom 240%.

Taking a guess: you're on a Mac, aren't you? I think that's a result of some erratic line height computation that we get with the default Times font; if you change your default to Times New Roman, for example, it'll be more stable. (See bug 832313.)

Comment 6

[Brad Werth [:bradwerth]]

(In reply to Jonathan Kew (:jfkthame) from comment #5)
> Taking a guess: you're on a Mac, aren't you? I think that's a result of some
> erratic line height computation that we get with the default Times font; if
> you change your default to Times New Roman, for example, it'll be more
> stable. (See bug 832313.)

I am indeed on OS X and from reading the other bugs I see there are still problems with calculating continuous line heights for some fonts. Regardless of that issue, it seems there may be an additional effect here. I don't think that the discontinous line height calculation explains why this testcase has a different rendering outcome when zooming from 170% -> 200% compared to zooming from 240% -> 200%.

Comment 7

[Brad Werth [:bradwerth]]

(In reply to Brad Werth [:bradwerth] from comment #6)
> I am indeed on OS X and from reading the other bugs I see there are still
> problems with calculating continuous line heights for some fonts. Regardless
> of that issue, it seems there may be an additional effect here. I don't
> think that the discontinous line height calculation explains why this
> testcase has a different rendering outcome when zooming from 170% -> 200%
> compared to zooming from 240% -> 200%.

I was wrong; changing to a default font with sane font metrics does resolve the zooming problem.

Comment 8

[Jonathan Kew [:jfkthame]]

I think the basic problem here is that "shrink-wrapping" a frame doesn't work during initial reflow when its contents have an orthogonal writing mode.

Note that things work fine if the orthogonal writing mode is applied to the inline-block element itself:

data:text/html,a<span style="display:inline-block;border:1px solid red;writing-mode:vertical-lr;"><span>b</span></span>c

but fail if we move it to the inner element:

data:text/html,a<span style="display:inline-block;border:1px solid red;"><span style="writing-mode:vertical-lr;">b</span></span>c

(Border added to make it clearer that the inline-block frame is getting a block-size of zero.)

The same problem will occur with other cases where we shrink-wrap the content, such as floats:

data:text/html,a<span style="float:left;border:1px solid red;"><span style="writing-mode:vertical-lr;">b</span></span>c

Or absolute positioning:

data:text/html,a<span style="position:absolute;border:1px solid red;"><span style="writing-mode:vertical-lr;">b</span></span>c

And to confirm that it applies equally to horizontal content within a vertical inline-block element, as the same issue of needing to shrink-wrap in the block direction of the content applies there:

data:text/html,<div style="writing-mode:vertical-rl">a<span style="display:inline-block;border:1px solid red;"><span style="writing-mode:horizontal-tb;">b</span></span>c

In all these cases, triggering an extra reflow (e.g. by zooming) will fix the rendering; the red border around the "b" will show that it now knows its proper size.

Comment 9

[Jonathan Kew [:jfkthame]]

A little more poking around confirms that these are all examples where we're running into the case where nsLayoutUtils::IntrinsicForAxis gives up in despair, like this:

      // XXX Unfortunately, we probably don't know this yet, so this is wrong...
      // but it's not clear what we should do. If aFrame's inline size hasn't
      // been determined yet, we can't necessarily figure out its block size
      // either. For now, authors who put orthogonal elements into things like
      // buttons or table cells may have to explicitly provide sizes rather
      // than expecting intrinsic sizing to work "perfectly" in underspecified
      // cases.
      result = aFrame->BSize();

https://dxr.mozilla.org/mozilla-central/rev/f40960c63bfac865d510ec9da42eeed74c384082/layout/base/nsLayoutUtils.cpp#4997-5004

Comment 10

[Gérard Talbot]

attachment 8802331 [details] is very similar to the test:

http://test.csswg.org/suites/css-writing-modes-3_dev/nightly-unstable/html/orthogonal-parent-shrink-to-fit-001a.htm

The differences are: 
- no doctype in attachment 8802331 [details], although this absence does not seem to make a significant difference
- the use of 'sideways-lr' in attachment 8802331 [details]; we really should prefer to use 'vertical-rl' instead so that we can compare rendered layout with other browsers (Chrome 50+, Edge 16, Safari 10.x, Prince 11, etc.). 'sideways-lr' is CSS4.
- The following inline element is an inline-block in attachment 8802331 [details]

Comment 12

[Daniel Holbert [:dholbert]]

I think this is a version of bug 1166120 -- marking as dependency for now, though it may really be a duplicate.