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

NEW
Unassigned

Status

()

4 years ago
23 days ago

People

(Reporter: kojiishi, Unassigned)

Tracking

(Blocks: 6 bugs, {css3, testcase})

Trunk
css3, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
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

Updated

4 years ago
Blocks: 145503
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.
(Reporter)

Comment 2

4 years ago
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

3 years ago
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
Created attachment 8631590 [details] [diff] [review]
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).
Created attachment 8631591 [details] [diff] [review]
Patch 2: assign the correct inline size to table cells that create an orthogonal flow
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
Created attachment 8631592 [details] [diff] [review]
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

Updated

3 years ago
Version: 41 Branch → Trunk

Updated

3 years ago
See Also: → bug 1185430

Comment 10

3 years ago
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

3 years ago
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

3 years ago
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

3 years ago
> 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.

Updated

3 years ago
Blocks: 1272181

Updated

a year ago
Duplicate of this bug: 1351257

Comment 15

a year ago
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: 1310551
Blocks: 1311208
Blocks: 1332555
See Also: bug 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
You need to log in before you can comment on or make changes to this bug.