> I have a fix for that, but I can't land it, since these tests would fail.

If you have a CL that makes world more correct, but causes additional tests
to fail, land the CL.

Landing the CL will make bugs more visible.

Right. "Can't" was a bit strong. :) But I prefer to do things in the right order if I can. My fix will fix one test and break four others...

(assigned the wrong bug to myself - not working on this one at the moment)

Thanks for looking into this, Aleks. I made some observations yesterday, that I thought I'd share:

First of all, three levels of writing mode roots isn't necessary. Two is enough. See attachment.

Deleted: tc-two-levels.html 367 bytes

tc-two-levels.html 367 bytes View Download

Secondly, I found out what are we supposed to do here. The spec is here: https://www.w3.org/TR/css-writing-modes-3/#orthogonal-auto

When it comes to calculating the block size of the inner writing mode root (see previous attachment), which will be used as min/max inline size for the outer writing mode root, Edge and legacy Blink use the initial containing block to set the inline size of the inner writing mode root, then lay out, and then use the resulting block size as min/max inline size in the outer writing mode root. This seems to be what the spec suggests. Firefox, on the other hand, doesn't handle this and just sets the min/max inline size contribution from the inner writing mode root to 0.

In LayoutNG the code that controls this is in NGBlockNode::ComputeMinMaxSize(), in the "if (!IsParallelWritingMode(..." section. We currently use a zero-sized constraint space, which explains why the outer writing mode root gets so tall (see previous attachment).

So this is hopefully just a matter of implementing what the spec says. Just using the initial containing block could be a good start. Honoring the definite sizes (if any) of the containing block would be even better, of course.

Hope this helps.

I've looked into this briefly, but you are way ahead of me on understanding this one, so I will unassign. I took it on thinking problem might be vrl painting, which I am familiar with.

To generate spec-compliant constraint space for orthogonal child, containing block inline_size is needed, and that value is currently not available inside 
NGBlockNode::ComputeMinMaxSize.

Since I have not worked with MinMax before, I am not best qualified to take this on.

>To generate spec-compliant constraint space for orthogonal child, containing 
> block inline_size is needed, and that value is currently not available inside 
> NGBlockNode::ComputeMinMaxSize.

Sorry, why do you say that? We do have a constraint_space argument here. Is it just a matter of the right caller passing in the constraint space?

As I mentioned, I am not qualified for this bug :)

NGBlockNode::ComputeMinMaxSize's constraint_space defaults to null, and does get called with null. I think in gdb I saw it being null, and assumed it can't be used.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4049f6391132a1126082c5ec6d1606b126495ae2

commit 4049f6391132a1126082c5ec6d1606b126495ae2
Author: Morten Stenshorne <mstensho@chromium.org>
Date: Thu Jun 07 22:44:41 2018

[LayoutNG] Orthogonal flows need available inline size for min/max calculation.

Provide a suitable constraint space when calculating min/max inline
sizes for an orthogonal flow root. ComputeMinMaxSize() in NGBlockNode
typically ended up creating its zero-sized constraint space, which would
typically result in large block sizes (since there'd e.g. only be space
for one word per line).

Set percentage resolution size too, instead of leaving it at 0x0.
Percentages are often unresolvable (i.e. indefinite), in which case we
should of course refrain from resolving them, rather than resolving the
percentage against zero (which we used to do).

Add a DCHECK that we're always provided with a constraint space when
calculating min/max for orthogonal flows, as using the zero-size one
will not produce the correct result.

Bug:  848225 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_layout_ng
Change-Id: Ic0aac380b2b733d3a55b25396c89584e4468899d
Reviewed-on: https://chromium-review.googlesource.com/1090845
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Aleks Totic <atotic@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#565446}
[modify] https://crrev.com/4049f6391132a1126082c5ec6d1606b126495ae2/third_party/WebKit/LayoutTests/FlagExpectations/enable-blink-features=LayoutNG
[modify] https://crrev.com/4049f6391132a1126082c5ec6d1606b126495ae2/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/4049f6391132a1126082c5ec6d1606b126495ae2/third_party/WebKit/LayoutTests/external/wpt/css/css-writing-modes/reference/three-levels-of-orthogonal-flows.html
[add] https://crrev.com/4049f6391132a1126082c5ec6d1606b126495ae2/third_party/WebKit/LayoutTests/external/wpt/css/css-writing-modes/reference/two-levels-of-orthogonal-flows-fixed.html
[add] https://crrev.com/4049f6391132a1126082c5ec6d1606b126495ae2/third_party/WebKit/LayoutTests/external/wpt/css/css-writing-modes/reference/two-levels-of-orthogonal-flows-percentage.html
[add] https://crrev.com/4049f6391132a1126082c5ec6d1606b126495ae2/third_party/WebKit/LayoutTests/external/wpt/css/css-writing-modes/reference/two-levels-of-orthogonal-flows.html
[add] https://crrev.com/4049f6391132a1126082c5ec6d1606b126495ae2/third_party/WebKit/LayoutTests/external/wpt/css/css-writing-modes/three-levels-of-orthogonal-flows.html
[add] https://crrev.com/4049f6391132a1126082c5ec6d1606b126495ae2/third_party/WebKit/LayoutTests/external/wpt/css/css-writing-modes/two-levels-of-orthogonal-flows-fixed.html
[add] https://crrev.com/4049f6391132a1126082c5ec6d1606b126495ae2/third_party/WebKit/LayoutTests/external/wpt/css/css-writing-modes/two-levels-of-orthogonal-flows-percentage.html
[add] https://crrev.com/4049f6391132a1126082c5ec6d1606b126495ae2/third_party/WebKit/LayoutTests/external/wpt/css/css-writing-modes/two-levels-of-orthogonal-flows.html
[modify] https://crrev.com/4049f6391132a1126082c5ec6d1606b126495ae2/third_party/blink/renderer/core/layout/ng/ng_block_layout_algorithm.cc
[modify] https://crrev.com/4049f6391132a1126082c5ec6d1606b126495ae2/third_party/blink/renderer/core/layout/ng/ng_block_node.cc
[modify] https://crrev.com/4049f6391132a1126082c5ec6d1606b126495ae2/third_party/blink/renderer/core/layout/ng/ng_block_node.h
[modify] https://crrev.com/4049f6391132a1126082c5ec6d1606b126495ae2/third_party/blink/renderer/core/layout/ng/ng_length_utils.cc