• type=number with min/max 0/999999
  • desktop Chrome (54.0 on Ubuntu 16.04): works as expected (which means that it accepts invalid unpadded input like 1), non-digits are silently swallowed in type / paste). There is spinner behavior on up/down arrows and mouse wheel.
  • desktop Firefox (50.0 on Ubuntu 16.04): allows typing in any input but then shows a validation error. Accepts spaces though (I use Hungarian as a fallback language which uses space as the thousands separator so could be a byproduct of that). Otherwise same as Chrome.
  • mobile Chrome (54.0 / 7.0): shows numeric keyboard (the same one you get with the 123 button), same behavior as desktop Chrome
• type=number with pattern [0-9]{6} and min/max
  • desktop Chrome: same as above, pattern gets ignored (this seems legit per the WHATWG spec)
  • desktop Firefox: same as above
  • mobile Chrome: same as above
• type=tel
  • desktop Chrome: works as expected, accepts any character
  • desktop Firefox: same as Chrome
  • mobile Chrome: shows a different numeric keyboard; seems about equally useful
• type=tel with pattern [0-9]{6}
  • desktop Chrome: allows typing in non-digits but then shows a validation error
  • desktop Firefox: same as Chrome
  • mobile Chrome: same
• type=text with pattern [0-9]{6}
  • desktop Chrome: allows typing in spaces but then shows a validation error
  • desktop Firefox: same as Chrome
  • mobile Chrome: shows standard keyboard (also with [0-9]*)

Mobile Firefox (50.0 / 7.0): nothing suprising (behaves as desktop Firefox, keyboard selection is as mobile Chrome). There is a nasty bug with the viewport jumping around when typing into the field (on JSFiddle at least) , but that affects any input field.

That's all the devices / browsers I have on me; more testing welcome.

I just realized I have been using SwiftKey (a popular input app for Android). The default Google keyboard is much better optimized for number:

	type="number"	type="tel"
Google keyboard
SwiftKey keyboard

cc @DanielFriesen who apparently blogged about this problem some years ago.

Note that the field itself needs to accept scratch tokens too, which currently match /^[A-Z2-7]{16}$/, so solutions that rely on supplying a number-only pattern would be problematic.

Ugh, didn't realize scratch tokens are non-numeric (other 2FA applications that I have seen use numbers, typically 10-digit).

Would it be worth having separate input fields? A numeric input for the phone code, and a forgotten-password-style link saying "enter a scratch token" which changes the help text and the input field characteristics. That's how e.g. Google does it (although they have a bunch of other options apart from TOTP and scratch tokens).

Change 332419 had a related patch set uploaded (by SamanthaNguyen):
0.2.3 - Change input type field for token to int

https://gerrit.wikimedia.org/r/332419

Change 332419 abandoned by SamanthaNguyen:
0.2.3 - Change input type field for token to int

Reason:
Temporarily abandoning per comments in https://phabricator.wikimedia.org/T151738

https://gerrit.wikimedia.org/r/332419

Does T289086: Allow iOS/macOS/iPadOS to autofill 2fa codes improve/change/whatever any of this handling?

In T151738#9425936, @Reedy wrote:

Does T289086: Allow iOS/macOS/iPadOS to autofill 2fa codes improve/change/whatever any of this handling?

At least on Chrome on Android, I get the normal keyboard.

In hindsight, I'm not sure how useful this is. Does anybody every type in 2FA codes by hand on mobile? It would be nice to have some instrumentation on this...