1443284 - percentage height in auto-height table cell in fixed-height table is treated as auto

Status: NEW

(Core :: Layout: Tables, defect, P3)

Description

[Jan de Mooij [:jandem]]

Attachment: Testcase

In Chrome the menu is easier to use because the "hover area" for the menu items is bigger.

I reduced it to the attached 26-line testcase. Note how in Chrome and Safari, the green element is much bigger than in Firefox.

I don't know if this is a Gecko bug but filing just in case.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This sounded familiar, but the only related things I found so far are bug 601931 and bug 1386982, neither of which is really right.

Resummarizing to make it clear what's actually going on here.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase with just a vanilla table, block, no flexbox

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (using "display:block" on innermost element, and with red background on ancestor that shows up in Firefox)

The previous testcase used 'display:flex' on the innermost element, but this happens for 'display:block' as well, as shown in this testcase.

(For extra emphasis, I'm adding a red background on the fixed-height ancestor here. This red background is shown in Firefox, but in Chrome it gets covered up by the lime area.)

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #1)
> This sounded familiar, but the only related things I found so far are
> bug 601931 and bug 1386982, neither of which is really right.

This actually looks quite a lot like bug 601931.  Both that bug & this bug have a "height:100%" child of a table-cell -- and we disregard the percent height, whereas Chrome and Edge (and I assume WebKit) resolve it.

Comment 5

[Daniel Holbert [:dholbert]]

(Oh, I guess in bug 601931, the percent-height basis ultimately comes from another cell in the same row, whereas in this case it comes from the table itself. Not sure if that makes a difference or to what extent this table behavior is specced these days...)

Comment 6

[Jet Villegas (inactive)]

[Triage 2018/03/23 - P3]

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: reference case (/ suggested workaround) for testcase 3

FWIW, for workaround purposes: if a site is hitting this bug, they may be able to get things working by:
 (a) adding an explicit "display:table-cell" wrapper (which we've already got in the testcases here)
 (b) styling that wrapper with "height:100%" (which I'm doing in this reference case).

This resolves the "broken chain" of height resolution between the inner percent-height block and the outer fixed-height table.  The inner block resolves its percent height against its cell (its containing block), so if the cell has a specified height (e.g. height:100%) which can be resolved against the table, then all is well.

Comment 8

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 9

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 10

[Thomas Wisniewski [:twisniewski]]

The three sites here no longer seem to have issues (greetz's menu works for me on my phone, mitsubishi-motors.es changed their layout, and photos load fine for me on jno.1g.fi). As we know of no other broken sites at the moment, unsetting webcompat priority.