With non-native theme, number inputs have zero padding-inline-end by
default, so otherwise the test would fail by a few pixels.

Hmm, I feel like this test-failure is actually pointing out a bug (or at least a notable behavior-change).

In Gecko, Blink, WebKit, and EdgeHTML (Edge 18), <input type="number"> is always the same size as a similarly-styled textfield. (Each pair of widgets in my attached testcase have the same width.) But when I enable the non-native theme, then the number widget ends up being a little bit skinnier. That's why the reftest is failing.

That invariant seems like something intentional, and something that we should be wary about changing... Perhaps that's really what we should be fixing here?

This means that the number input by default shows some white space to
the right of the spinners. I think it's probably not the end of the
world, and depending on the different trade-offs we might want to do
this instead of fixing the test.

Depends on D103270

So, on one hand, you're right, and it's a known issue (in the sense that I know it's caused by this line).

That being said, this test is only testing for text-decoration to apply to the number input, so it doesn't seem the right to test that sizing there, and it's the only remaining number input failure.

So, would you be fine landing the test fix for now, and moving the patch in comment 4 to some follow-up? I suspect that might need a bit of discussion since that diverges from the UX designs and so on...

Yeah, that sounds fine - let's do that.

Comment on attachment 9199722 [details]
Bug 1689231 - Remove number-input padding special-case so that we size them the same way as text controls. r=spohl,mstange

Revision D103271 was moved to bug 1689477. Setting attachment 9199722 [details] to obsolete.

https://hg.mozilla.org/mozilla-central/rev/a226f63871cd