I confirmed that our rendering of the attached testcases is consistent with Chrome's implementation, with the exception of the progress and meter frame in testcase 1, which are smaller there because Chrome's UA stylesheet seems to assign those an explicit length-valued `width` (or `inline-size`) which disables the auto-sizing `stretch` behavior. (Relatedly, the `<input type="color">` seems to be small for us and for Chrome in testcase 1, for the same reason; we both give that element an explicit size in the UA stylesheet.)
Bug 1740580 Comment 29 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I confirmed that (in a patched build) our rendering of the attached testcases is consistent with Chrome's implementation, with the exception of the progress and meter frame in testcase 1, which are smaller there because Chrome's UA stylesheet seems to assign those an explicit length-valued `width` (or `inline-size`) which disables the auto-sizing `stretch` behavior. (Relatedly, the `<input type="color">` seems to be small for us and for Chrome in testcase 1, for the same reason; we both give that element an explicit size in the UA stylesheet.)
I confirmed that (in a patched build) our rendering of the attached testcases is consistent with Chrome's implementation, with the exception of the progress and meter frame in testcase 1, which are smaller in Chrome because Chrome's UA stylesheet seems to assign those an explicit length-valued `width` (or `inline-size`) which disables the auto-sizing `stretch` behavior. (That's sort-of them exposing an implementation detail, and it's arguably better on our side that we're not exposing that.) (Relatedly, the `<input type="color">` seems to be small for us and for Chrome in testcase 1, for the same reason; we both give that element an explicit size in the UA stylesheet.)
I confirmed that (in a patched build) our rendering of the attached testcases is consistent with Chrome's implementation, with the exception of the progress and meter frame in testcase 1, which are smaller in Chrome because Chrome's UA stylesheet seems to assign those an explicit length-valued `width` (or `inline-size`) which disables the auto-sizing `stretch` behavior. (That's sort-of them exposing an implementation detail, and it's arguably better on our side that we're not exposing that.) (Relatedly, the `<input type="color">` seems to be small for us and for Chrome in testcase 1, for the same reason; we both give that element an explicit size in the UA stylesheet, [here](https://searchfox.org/mozilla-central/rev/f63ca2952da98e0817bdae0ddf1314281a497106/layout/style/res/forms.css#511-513) on our side.)
I confirmed that (in a patched build) our rendering of the attached testcases is consistent with Chrome's implementation, with the exception of the progress and meter frame in testcase 1, which are smaller in Chrome because Chrome's UA stylesheet seems to assign those an explicit length-valued `width` (or `inline-size`) which disables the auto-sizing `stretch` behavior. (That's sort-of them exposing an implementation detail, and it's arguably better on our side that we're not exposing that.) (Relatedly, the `<input type="color">` button seems to stand out as being small for us and for Chrome in testcase 1, for the same reason; we both give that element an explicit size in the UA stylesheet -- [here](https://searchfox.org/mozilla-central/rev/f63ca2952da98e0817bdae0ddf1314281a497106/layout/style/res/forms.css#511-513) on our side -- and the presence of that style disables the `width:`auto stretch behavior that it would otherwise get.)