1166120 - Shrink-to-fit width calculates to zero when children are in orthogonal flow

Status: NEW

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

Description

[Koji Ishii]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150517030204

Steps to reproduce:

1. Open the CSS WG test page
http://test.csswg.org/harness/test/css-writing-modes-3_dev/single/orthogonal-parent-shrink-to-fit-001/



Actual results:

All tests fail.


Expected results:

All test pass.

A note was recently added to the spec to clarify this behavior:
http://dev.w3.org/csswg/css-writing-modes-3/#orthogonal-shrink-to-fit

Comment 1

[Simon Montagu :smontagu]

The tests seem to pass if I zoom in or out after loading the page. I'm not sure if this is a bug or a problem with the test.

Comment 2

[Koji Ishii]

True, that's a tricky part. Re-layout oftentimes make the result correct, but the first-time layout after load, or after properties of the test target change, it fails.

The spec above requires if shrink-to-fit and its children are orthogonal, layout children first and get logical height. This is a reverse of dependency from the normal flow.

My guess is that Gecko does not follow this part of the spec, but caches the logical height of the child or the preferred width of the parent.

So in the first layout after created/invalidated, the logical height of the child is zero, and the test fails. But then children are layout, which will calculate the correct logical height of the child.

When re-layout happens, and the child is not invalidated, the parent sees the cached logical height, which is the correct value, so the test passes.

Failures on the first layout but pass on the second is I think a proof of Gecko have not implemented the reverse of the dependency.

I had a bit of conversation with dbaron on this, so added him to cc.

Comment 3

[Gérard Talbot]

Quick draft test for this bug report:

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s73-orthogonal-table-cell-003.xht

CONFIRMING

Marking as NEW

Comment 4

[Simon Montagu :smontagu]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=73e96f814c7d

The patch in this try push fixes the basic table cell size issue in the testcase in comment 3, but not yet any of the tests linked from comment 0 (not even the table cell tests, and certainly not the float and inline-block tests).

Comment 5

[Simon Montagu :smontagu]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=06f0e58e32ab

Fixes 8 out of the 24 tests in http://test.csswg.org/harness/test/css-writing-modes-3_dev/single/orthogonal-parent-shrink-to-fit-001/

Comment 6

[Simon Montagu :smontagu]

Attachment: Patch 1 v.1: add a method to identify elements that create an orthogonal flow

I'm going to attach my current patch set now that it at least doesn't cause regressions on try, even though it still has some fundamental issues. Chiefly that it only identifies orthogonal flows immediately below the containing element, but that really needs to get propagated up to all containers (this seems to be the chief reason for the remaining test failures).

Comment 7

[Simon Montagu :smontagu]

Attachment: Patch 2: assign the correct inline size to table cells that create an orthogonal flow

Comment 8

[Simon Montagu :smontagu]

Attachment: Patch 3 v.1: convert blockEndEdgeOfChildren to a LogicalSize, update the inline edge from lines with orthogonal contents, and include the inline edge in ConsiderEndOfChildren

Comment 9

[Simon Montagu :smontagu]

The 3 attached patches are the same content, but more logically distributed, as https://treeherder.mozilla.org/#/jobs?repo=try&revision=4143326a3151. They pass 12 out of 24 tests in http://test.csswg.org/harness/test/css-writing-modes-3_dev/single/orthogonal-parent-shrink-to-fit-001/

Comment 10

[Gérard Talbot]

Bug 1185430 is related to this bug. In the mega-test

http://test.csswg.org/source/css-writing-modes-3/orthogonal-parent-shrink-to-fit-001/

inline-block, table-cells, block boxes are being tested. Bug 1185430 is a variant of sub-test 11, of

http://test.csswg.org/source/css-writing-modes-3/orthogonal-parent-shrink-to-fit-001k.html

If/when this bug 1166120 gets fixed, then bug 1185430 should be revisited.

Comment 11

[Gérard Talbot]

2 additional tests:

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/orthogonal-vrl-table-cells-001.html

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/orthogonal-vrl-table-cells-002.html

Firefox 46.0a1 buildID=20151229030216 and Chrome 49.0.2593.0 fail those 2 tests.

MS-Edge passes orthogonal-vrl-table-cells-001 but I think it fails orthogonal-vrl-table-cells-002 as both cells' outer vertical edges should be the same.

Comment 12

[Gérard Talbot]

Firefox 45.0 (stable release) buildID=20160304114926 now passes

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s73-orthogonal-table-cell-003.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/orthogonal-vrl-table-cells-001.html

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/orthogonal-vrl-table-cells-002.html

while Firefox 47.0a1 buildID=20160304163750 fails those 3 tests. This suggests to me that those 3 tests are probably not suited for this bug report but maybe for bug 1227616 or some other bug report.

Comment 13

[Gérard Talbot]

> Firefox 45.0 (stable release) buildID=20160304114926 now passes
> 
> http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s73-orthogonal-
> table-cell-003.xht

(...)

Firefox 45 (final release) buildID=20160304114926 and Firefox 48.0a1 buildID=20160406030221 all fail these 3 tests. The previous comment is incorrect.

Comment 15

[Gérard Talbot]

2 additional tests (testing a table with realistical tabular data; both border-collapse models tested):


http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s73-orthogonal-vrl-table-cells-004.xht


http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s73-orthogonal-vrl-table-cells-006.xht


The tester must have "Liberation Sans" font or Arial font installed on his/her system.

Note that Firefox fails to render 'text-align: left' correctly for cells in orthogonal flow.

Comment 16

[Daniel Holbert [:dholbert]]

[Unassigning from smontagu to reflect reality, since he's less active these days & probably isn't working on this.]