jazzband
IntegerField in forms
Hi,
This is more of a question/suggestion than an issue.
various forms in two_factor use an IntegerField (DeviceValidationForm, AuthenticationTokenForm, TOTPDeviceForm) use IntegerField.
The form widget of an IntegerField varies depending on the version of Django:
- in Django 1.5 the default widget for an IntegerField is TextInput
- in Django 1.6+ it is "NumberInput when Field.localize is False, else TextInput."
I just got slightly burned with this on an upgrade from 1.5 to 1.6 in the sense that a NumberInput has up/down arrows which don't really make a lot of sense in the context of inputting a verification code (also I hadn't defined CSS styles for a "number" field so the page suddenly looked weird but that is beside the point and I get that this is just the type of small thing that can get messed up by a major Django upgrade)
Would it make sense to define localize on those fields to force to a TextInput (specifically for the reason that "number" seems to be a non-ideal field for the verification code type given that the up/down arrows are not really suitable when entering a numeric code i.e they are more suitable for dates or such like)?
Just a thought/suggestion.
The benefit of having <input type=number/> is that on mobile devices (such as the iPhone) will automatically show the keypad instead of the keyboard. I agree that the up/down controls of Chrome (and possibly other browsers) look kinda out of place.
ok - fair enough. My webapp isn't running on mobile devices but I get the use-case. It might be nice to be able to "localize" the fields somehow via settings (for the non-mobile use-case) but I guess that may be overkill to have in two_factor.
I think this deserves another look. The usability on this at the moment is quite bad as you can enter your number and then inadvertently use the scrollwheel, which will change the number in the input box, leading to frustration.
We already use inputmode="numeric", which is enough for numeric entry on phones.
@claudep, I guess you are doing the bulk of the work here now, what do you think?
As the author of #479, I can only agree :smile: Do you think you would be able to find the time to suggest a pull request in the same vein?
I can try to put something together over the weekend / next week, if I can scrape the time together
Noting that DeviceValidationForm and TOTPDeviceForm have a bug where leading zeros will get stripped, so copying #479 to those fields will fix that problem in addition to the original widget issue.
