Notably, the testcase doesn't bother to set the `font-size` here right now, so we've just got the UA default font-size for `input`, which in my case happens to be `13.3333px`. It's not surprising that we might get a 1px discrepancy in the line-height when laying out an odd, fractional-sized line of text using its ideographic baseline vs. its central baseline (if we do pixel snapping or similar rounding at the edges of the line). So: I think the testcase is curently unsound, and we should fix it to use Ahem font with 30px font-size, as in bug 1808997, for a more predictable & reliably-whole-pixel-valued baseline-position, and hence a predictably consistent widget size regardless of writing-mode.
Bug 1823516 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Notably, the testcase doesn't explicitly set any particular `font-size` here right now, so we've just got the UA default font-size for `input`, which in my case happens to be `13.3333px`. It's not surprising that we might get a 1px discrepancy in the line-height when laying out an odd, fractional-sized line of text using its ideographic baseline vs. its central baseline (if we do pixel snapping or similar rounding at the edges of the line). So: I think the testcase is curently unsound, and we should fix it to use Ahem font with 30px font-size, as in bug 1808997, for a more predictable & reliably-whole-pixel-valued baseline-position, and hence a predictably consistent widget size regardless of writing-mode.