height:100% on a block child inside an auto-sized table-cell within a definite size table doesn't resolve the percentage
Categories
(Core :: Layout: Tables, defect, P3)
Tracking
()
| Webcompat Priority | P2 |
People
(Reporter: miketaylr, Unassigned)
References
(Blocks 2 open bugs, )
Details
(Keywords: testcase, webcompat:platform-bug)
Attachments
(3 files)
Originally reported at https://github.com/webcompat/web-bugs/issues/44743.
STR: Open the attached test case
Expected: In Chrome, the green iframe is 100% high
Actual: In firefox, it's not.
Apparently the site is relying on Chrome's behavior.
Body of TC for convenience:
<!doctype html>
<style>
table iframe {
width: 100%;
height: 100%;
}
table {
position: absolute;
left: 0px;
width: 100%;
height: calc(100% - 46px);
}
</style>
<table>
<tr>
<td>
<iframe srcdoc="<div style='position:absolute;width:100%;height:100%;background:green;'></div>"
</td>
</tr>
</table>
|
Reporter | |
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
|
|
||
Comment 2•5 years ago
|
||
It seems to be more general than just <iframe> and an abs.pos. table, so rephrasing the summary.
I'm not sure what specs applies to this case, but I'm guessing both css-tables and css-sizing.
|
|
||
Comment 3•5 years ago
|
||
So I guess the definition of "definite size" https://drafts.csswg.org/css-sizing-3/#definite and "Computing the table height" https://drafts.csswg.org/css-tables-3/#computing-the-table-height should be combined to determine the correct rendering in this case.
|
|
||
Updated•5 years ago
|
Looks like the same problem with TEXTAREA in latest released build of Firefox (71):
https://addons.mozilla.org/en-US/firefox/addon/translator_extension/
bottom textarea in popup window lost its height.
In case of Translator extension - this is broken back compatibility! In Firefox <= 70.xx all was fine.
|
||
Comment 6•5 years ago
|
||
(In reply to sailormax from comment #5)
In case of Translator extension - this is broken back compatibility! In Firefox <= 70.xx all was fine.
Could you attach a test-case that used to work? Thanks.
Sample attached.
Second textarea lost its height, because of not concrete height of parent (start with Firefox 71)
|
|
||
Comment 8•5 years ago
|
||
I filed bug 1605868 for that, as that was indeed a regression (while the original test-case here didn't seem to be).
|
|
Reporter | |
Updated•4 years ago
|
|
||
Comment 10•3 years ago
|
||
This came up again, via https://webcompat.com/issues/80763 . I initially filed bug 1734054 before realizing we already had this bug.
One bit of new information here: it seems we get the right layout if you add height:100% to the table cell, and we keep the right layout even if you then dynamically revert that change. See for example my testcase https://bugzilla.mozilla.org/attachment.cgi?id=9244285 , where the layout changes when you click the button (even though there's no persistent change to the DOM or styles).
|
|
||
Updated•3 years ago
|
|
||
Comment 11•3 years ago
|
||
My friend points to me a site is broken in Firefox, and I manage to reduce a testcase in https://jsfiddle.net/aethanyc/8p10exck/. Looks like exactly this bug.
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
||
Updated•5 months ago
|
|
||
Comment 12•4 months ago
|
||
This is still reproducible based on https://webcompat.com/issues/80763 with extensions.webcompat.perform_injections set to false.
Environment:
Operating system: Windows 10
Browsers tested: Firefox Nightly 128.0a1 (2024-05-29) / Chrome 125.0.6422.113
|
||
Updated•8 days ago
|
Description
•