1244601 - confusion about auto margins when laying out children of table cell that is orthogonal to its table (writing-modes)

Status: NEW

(Core :: Layout, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: simplified testcase

In the CSS WG meeting just now, the list of tests that are preventing CSS Writing Modes from exiting CR came up:
http://test.csswg.org/harness/results/css-writing-modes-3_dev/grouped/filter/17/

I started looking at the first of these failures that Gecko fails:
http://test.csswg.org/harness/test/css-writing-modes-3_dev/single/block-flow-direction-slr-058/format/html5/
which seems to have a problem in common with a number of the other tests that Gecko fails in the same block.

I have a simplified testcase for this, which I have debugged a bit.

In particular, we end up with a problem in nsHTMLReflowState::CalculateBlockSideMargins when we're computing the inline-side margins for a child of the table cell.  The big problem here is that we end up with cbWM reflecting the table's (horizontal) writing mode rather than the table cell's (vertical) writing mode.  In particular, we're laying out a frame whose parent is the anonymous block inside the table cell, but its containing block is its grandparent (the table cell).  Table cells override nsIFrame::GetWritingMode to return the table's writing mode, so cbWM ends up being for horizontal writing rather than the sideways-lr that is the writing-mode of both the div and its table-cell parent.

Then, somehow, we conclude that availMarginSpace is -1200 (the size of the left border of the child div), and give that div a negative right margin to balance that border because we believe that the containing block is operating in horizontal writing mode.

I still haven't investigated why the sizes (of either the cell or the negative availSize) are the way they are.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(The other interesting question here is whether the spec has the same bug.)

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to David Baron [:dbaron] ⌚️UTC+11 (busy, returning 8 February) from comment #0)
> In particular, we're
> laying out a frame whose parent is the anonymous block inside the table
> cell, but its containing block is its grandparent (the table cell).

We made the anonymous block not be a containing block in bug 522632, for what it's worth.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Given the "Applies To" lines in the spec, it may be that the right thing here is to remove the GetWritingMode override on nsTableCellFrame, since these properties are supposed to apply to table cells.

https://drafts.csswg.org/css-writing-modes/#propdef-writing-mode
https://drafts.csswg.org/css-writing-modes/#text-orientation

Comment 4

[Jonathan Kew [:jfkthame]]

(In reply to David Baron [:dbaron] ⌚️UTC+11 (busy, returning 8 February) from comment #3)
> Given the "Applies To" lines in the spec, it may be that the right thing
> here is to remove the GetWritingMode override on nsTableCellFrame, since
> these properties are supposed to apply to table cells.

Yes, I think that may well be the right way forward -- but it will require some fixup elsewhere in the table code, which currently depends on having a consistent writing mode throughout the table.

Setting a different mode on a cell generally has the expected effect on its content, because it gets inherited by the anonymous block inside, but as this bug illustrates, that's not sufficient.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(This is somewhat related to bug 1581718, which ended up fixing one of the four testcases affected.)