The first item should grow to fill its 400px column. The second should shrink to fit its 40px column. Both should stretch their height to fill the row size.

I suspect that the problem here is the definite inline/block-sizes specified in our UA sheet starting here: http://searchfox.org/mozilla-central/rev/8562d3859b89ac89f46690b9ed2c473e0728d6c0/layout/style/res/forms.css#932

I'll use this bug for the follow-up I talked about in bug 1481593 comment 3, although this patch goes beyond the 'stretch' issue reported here. So, the main problem is the explicit definite width/height specified in the UA sheet. That inhibits stretch sizing. Simply removing those declarations is OK since nsRangeFrame::ComputeAutoSize takes care of that anyway. I'm just updating it to use the values from the UA sheet. I'm also removing the tweak in GetPrefISize that treats themed/ non-themed controls differently. I don't see any such behavior in other UAs. Likewise for the non-zero GetMinimumWidgetSize (which we already lack on Windows anyway). In the UA sheet, I'm removing the padding (1px from the general <input> rule) and changing the margin to 2px. This is compatible with Chrome/Safari. I'm also enforcing that the child pseudo elements always inherit 'writing-mode' and 'direction' because it doesn't seem meaningful to have differences there compared to the principal box. I'm also changing them to have 'display:block' rather than 'inline-block'. That seems more appropriate since nsRangeFrame inherits nsContainerFrame and thus doesn't flow its child boxes in a block formatting context anyway. This also has the effect that the pseudos stretch to fill the parent box naturally so there's no need for them to have 'inline-size:100%'. Overall, I think this makes us compatible with Chrome/Safari, except for a minor issue on Windows where we apparently have GetWidgetBorder return a 1px border for some reason. I'm punting on that for now, but it seems like a rather nasty behavior since even if the author specifies a zero border it still ends up with a 1px computed border. It bit me when I wrote the -ref for the test and I had to add 'box-sizing:border-box' to work around it. We should probably investigate which controls have a non-zero GetWidgetBorder/ GetWidgetPadding and see if we can remove those...

(FYI, this should also fix 'stretch' alignment for <input type=range> as flex items, in case we have any bug open on that.)

Comment on attachment 9025327 [details] [diff] [review] Make intrinsic sizing for <input type=range> work properly and make its default margin/padding compatible with Chrome/Safari Review of attachment 9025327 [details] [diff] [review]: ----------------------------------------------------------------- I think this all looks good. Thanks for the explanation of what you're trying to achieve with this patch. That was helpful.

Pushed by mpalmgren@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/fda2edef30ab Make intrinsic sizing for <input type=range> work properly and make its default margin/padding compatible with Chrome/Safari. r=jwatt

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/14085 for changes under testing/web-platform/tests

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Upstream PR merged