Very high CSS <length> values may be misinterpreted due to NS_{UNCONSTRAINEDSIZE,INTRINSICSIZE,AUTOHEIGHT,AUTOOFFSET} being equal to nscoord_MAX
Categories
(Core :: Layout, defect, P3)
Tracking
()
People
(Reporter: andyearnshaw, Unassigned)
References
Details
(Keywords: parity-chrome)
Attachments
(1 file)
109 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Steps to reproduce:
- Create web page containing a solitary div with a height unsupported by Firefox (max is about 17187496px, but if you want to compare other browsers then you might want to double this value).
- Open the dev tools/element inspector and inspect the div
- Check both the computed height and
offsetHeight
Actual results:
The element has a computed height of 0px
Expected results:
According to the spec,
In cases where the used length cannot be supported, user agents must approximate it in the actual value.
0 is not an approximation of whatever very large number you enter. Both Chrome and Safari clamp the height to the maximum permitted value. Not sure on IE/Edge's behaviour.
Reporter | ||
Comment 1•5 years ago
|
||
I checked Edge in SauceLabs, it clamps like Safari and Chrome.
Comment 2•5 years ago
|
||
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:66.0) Gecko/20100101 Firefox/66.0
Build ID: 20190114014511
I managed to reproduce this issue on macOS 10.13.6 with the latest Firefox Nightly version 66.0a1.
Updated•5 years ago
|
Comment 3•5 years ago
|
||
I took a quick look, we're not clamping to zero, the style system properly propagates the number and layout clamps it.
We're treating the height as auto instead (you can see this easily if you add some text to the <div>
). This is because we're using the maximum value as auto
height:
Updated•5 years ago
|
Comment 4•5 years ago
|
||
I'd note that margins use a different constant just to get around this problem:
So not sure whether this behavior is intentional or not.
Comment 5•5 years ago
|
||
Let's see what try thinks of this: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5ee936775018f0de14187b4c33fbd6b2470b7f35
Comment 7•5 years ago
|
||
See bug 1547409. Moving webcompat whiteboard tags to project flags.
Updated•4 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Description
•