URL: https://codepen.io/lassediercks/pen/NywMxp
Browser / Version: Firefox 58.0
Operating System: Mac OS X 10.12
Tested Another Browser: Yes
Problem type: Design is broken
Description: The padding-top: 100%; causes the height to explode
Steps to Reproduce:
The Codepen url contains the bug in an isolated environment.
_From webcompat.com with ❤️_
I looked at the bug in Safari and Chrome and it didn't appear there.
@karlcow , a little help here, please!
@lasserdiercks oh come on… it's only 17 895 700 px high. 👹
This is a magical number I have already seen recently once in https://bugzilla.mozilla.org/show_bug.cgi?id=1358319
Also interesting is that if we set a height on the grid, aka the container, we get a reasonable behavior on the padding. for example 50px leads for me to 340px padding.
recently Firefox had an issue fixed for padding in percentage when vertical was 0 for flex container. Solved by https://bugzilla.mozilla.org/show_bug.cgi?id=958714 by @dholbert
I have the feeling that this magical number is Firefox saying, division by zero.
I have the feeling that this magical number is Firefox saying, division by zero.
That magical number (when multiplied by 60 to convert to "nscoord" units) is roughly 2^30 nscoord units, i.e. it's roughly nscoord_MAX -- and that's what Firefox uses internally to represent "unconstrained size". In this case, it may very well represent something along the lines of division by 0.
Anyway -- this is still broken (hugely tall) even in builds after bug 958714 landed, and I suspect this is a version of https://bugzilla.mozilla.org/show_bug.cgi?id=1434478 , or something related. CC @matspalmgren for thoughts / confirmation
Right, bug 1434478 will fix this (my WIP patches renders the testcase as in Chrome).
Duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1434478
Thanks a lot!
Most helpful comment
That magical number (when multiplied by 60 to convert to "nscoord" units) is roughly 2^30 nscoord units, i.e. it's roughly nscoord_MAX -- and that's what Firefox uses internally to represent "unconstrained size". In this case, it may very well represent something along the lines of division by 0.
Anyway -- this is still broken (hugely tall) even in builds after bug 958714 landed, and I suspect this is a version of https://bugzilla.mozilla.org/show_bug.cgi?id=1434478 , or something related. CC @matspalmgren for thoughts / confirmation