Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IntegerField in forms #84

Open
gardenia opened this issue Mar 3, 2015 · 7 comments
Open

IntegerField in forms #84

gardenia opened this issue Mar 3, 2015 · 7 comments
Labels

Comments

@gardenia
Copy link

gardenia commented Mar 3, 2015

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.

@Bouke
Copy link
Collaborator

Bouke commented Mar 3, 2015

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.

@gardenia
Copy link
Author

gardenia commented Mar 3, 2015

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.

@knyghty
Copy link
Member

knyghty commented Aug 11, 2023

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.

@knyghty knyghty reopened this Aug 11, 2023
@knyghty
Copy link
Member

knyghty commented Aug 11, 2023

@claudep, I guess you are doing the bulk of the work here now, what do you think?

@claudep
Copy link
Contributor

claudep commented Aug 11, 2023

As the author of #479, I can only agree 😄
Do you think you would be able to find the time to suggest a pull request in the same vein?

@knyghty
Copy link
Member

knyghty commented Aug 11, 2023

I can try to put something together over the weekend / next week, if I can scrape the time together

@crccheck
Copy link

crccheck commented Dec 4, 2023

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.

@moggers87 moggers87 removed the wontfix label Feb 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants