Open Bug 1166120 Opened 8 years ago Updated 5 days ago

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

Categories

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

defect

Tracking

()

People

(Reporter: kojii, Unassigned)

References

(Blocks 10 open bugs, )

Details

(Keywords: css3, testcase)

Attachments

(3 files)

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
Blocks: writing-mode
Component: Untriaged → Layout: Block and Inline
Keywords: css3
Product: Firefox → Core
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.
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.
Quick draft test for this bug report:

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

CONFIRMING

Marking as NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
OS: Unspecified → All
Hardware: Unspecified → All
Blocks: 1165797
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).
Assignee: nobody → smontagu
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).
Attachment #8631591 - Attachment description: Patch 2: sssign the correct inline size to table cells that create an orthogonal flow → Patch 2: assign the correct inline size to table cells that create an orthogonal flow
Version: 41 Branch → Trunk
See Also: → 1185430
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.
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.
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.
> 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.
Blocks: 1272181
See Also: → 1332555
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.
Blocks: 1332555
See Also: 1332555
[Unassigning from smontagu to reflect reality, since he's less active these days & probably isn't working on this.]
Assignee: smontagu → nobody
Summary: Shrink-to-fit width calculates to zero when children are in vertical flow → Shrink-to-fit width calculates to zero when children are in orthogonal flow
Blocks: 1696208
See Also: → 1765664
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.