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.

(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.

(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%.

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)

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.

(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.)

(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%.

(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.

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.

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

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]

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