[Django] #23075: NumberInput cross-browser issues and wrong error messages
Django
-----------------------------+----------------------
Reporter: sehmaschine | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.7-rc-1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+----------------------
Django recently introduced a NumberInput which is rendered with
type="number". While this seems like a good idea at first view, it leads
to a couple of issues with different browsers:
a) Safari removes (!) any invalid values from this input field. This leads
to unpredictable situations when trying to save with the admin.
b) Other browsers render non stylable error messages before (!) saving the
form: This contradicts the standard Django form behaviour with the admin,
when error messages are shown after (!) the form is being submitted.
I suggest using type="text" for any NumberInput or remove the field
altogether. The current behaviour with this field is cross-browser madness
and a conflict with how Django handles errors with forms.
--
Ticket URL: <https://code.djangoproject.com/ticket/23075>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
messages
-----------------------------+------------------------------------
Reporter: sehmaschine | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.7-rc-1
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by erikr):
* needs_better_patch: => 0
* stage: Unreviewed => Accepted
* needs_tests: => 0
* needs_docs: => 0
Comment:
I see the issue, but I'm not sure what the appropriate resolution is.
This is not limited to numbers: I've had this issue myself with URLField:
that is now `type="url"`, which enforces browser-specific validation, but
this is inconsistent across browsers. For example, `google.com` is valid
in django's URL validator, also accepted by Safari, but not by Chrome. So
while using type-specific fields is in general a good practice, we have
created browser-dependant inconsistent validation which is hard to
influence. And as you note, the behaviour between different fields may now
also be inconsistent: some are validated immediately, others only later.
These issues may also affect `EmailInput`. As a workaround for now, you
can still set the widget of any field you define to `forms.TextInput()`.
--
Ticket URL: <https://code.djangoproject.com/ticket/23075#comment:1>
Django
messages
-----------------------------+------------------------------------
Reporter: sehmaschine | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.7-rc-1
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by sehmaschine):
From my point of view, the appropriate solution is to use type="text"
until all issues are resolved with these types.
Especially with the admin interface, form validation should not be moved
to the frontend (unless otherwise clearly stated and consistently
integrated).
Besides, I think the "workaround" should be reversed:
Using type="text" should be the standard way of handling form fields. The
new types could be implemented with a widget – if you exactly know what
you're doing and if you are keen to accept the inconsitencies for your
users (or administrators).
If this solution is not accepted, I suggest adding a bold warning with the
release of Django 1.7: The new behaviour could lead to severe errors with
your application.
--
Ticket URL: <https://code.djangoproject.com/ticket/23075#comment:2>
Django
messages
-----------------------------+------------------------------------
Reporter: sehmaschine | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.7-rc-1
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by sehmaschine):
Here is an example in order to better understand the possible
consequences:
Let's say you have a Model with is edited using TabularInlines with the
admin interface. The Model consists of a couple of fields with one
DecimalField which is not required (blank=True). So far, an editor could
not save an inline row if the value of that DecimalField was wrong (e.g.
due to a simple typo). With the new behaviour, the whole inline-row is
being saved without any error message (at least with Safari). In my
opinion, this is a major shift in how the admin works with the new type-
specific fields.
--
Ticket URL: <https://code.djangoproject.com/ticket/23075#comment:3>
Django
messages
-----------------------------+------------------------------------
Reporter: sehmaschine | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.7-rc-1
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by claudep):
Note that these specific input types have been introduced in Django 1.6,
not 1.7.
--
Ticket URL: <https://code.djangoproject.com/ticket/23075#comment:4>
Django
messages
-----------------------------+------------------------------------
Reporter: sehmaschine | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.7-rc-1
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by erikr):
Thanks for the additional info. Personally, I'm inclined to make
`TextInput()` the default widget, but I've brought it up on the django-
developers mailing list for wider discussion:
https://groups.google.com/forum/#!topic/django-developers/TGwABHUPrw8
--
Ticket URL: <https://code.djangoproject.com/ticket/23075#comment:5>
Django
messages
-----------------------------+------------------------------------
Reporter: sehmaschine | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.7-rc-1
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timo):
While the input types were introduced in Django 1.6 as Claude said, they
weren't added to the admin until 1.7
(2a979d2a7bec485e4b90b7ae99ace0dd16faa948), so backwards compatibility
isn't an issue if we want to revert that.
--
Ticket URL: <https://code.djangoproject.com/ticket/23075#comment:6>
Django
messages
-----------------------------+------------------------------------
Reporter: sehmaschine | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.7-rc-1
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by sehmaschine):
I just tested with Django 1.6 and DecimalFields are being rendered as
type="number" with the admin.
--
Ticket URL: <https://code.djangoproject.com/ticket/23075#comment:7>
Django
messages
-----------------------------+------------------------------------
Reporter: sehmaschine | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.7-rc-1
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timo):
Yes, just `EmailInput` and `URLInput` were added to the admin in 1.7.
--
Ticket URL: <https://code.djangoproject.com/ticket/23075#comment:8>
Django
messages
-----------------------------+------------------------------------
Reporter: sehmaschine | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.7-rc-1
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by erikr):
* has_patch: 0 => 1
Comment:
I created https://github.com/django/django/pull/3105 in which I've
implemented the last solution I suggested in the mailing list thread:
I've had another look at this. The novalidate attribute on the form for
URL and email fields indeed disables the validation in both Chrome and
Safari. For number fields, I can reproduce Patrick's test: Safari will
still silently drop the value.
So, for URL and email fields, this issue is resolved by setting
novalidate on the form. I think we should document a recommendation for
users to add this attribute to their forms, and change the forms in the
admin to always include the novalidate attribute, as Bruno suggested.
This does not resolve the issue of Safari silently discarding invalid
numbers. I don't see a way to resolve that, other than to revert to the
text field. Perhaps this is a Safari bug. I haven't managed to find a
standard on what browsers should be doing in this case, but this behaviour
seems awful. But even if it is a Safari bug, that wouldn't fix the issue
for a while anyways. Overall, I'd rather go for the partial novalidate
solution for now, than do nothing at all.
--
Ticket URL: <https://code.djangoproject.com/ticket/23075#comment:9>
Django
messages
-----------------------------+---------------------------------------------
Reporter: sehmaschine | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.7-rc-1
Keywords: | Triage Stage: Ready for checkin
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/23075#comment:10>
Django
messages
-----------------------------+---------------------------------------------
Reporter: sehmaschine | Owner: nobody
Type: Bug | Status: closed
Component: Forms | Version: 1.7-rc-1
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Ready for checkin
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Erik Romijn <eromijn@…>):
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"cbdda28208c9c2aea479d5a482ff27bf37869d34"]:
{{{
#!CommitTicketReference repository=""
revision="cbdda28208c9c2aea479d5a482ff27bf37869d34"
Fixed #23075 -- Added documentation on novalidate attribute and made it
default for admin
Thanks to sehmaschine for the report and to Tim Graham for the review.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23075#comment:11>
Django
messages
-----------------------------+---------------------------------------------
Reporter: sehmaschine | Owner: nobody
Type: Bug | Status: closed
Component: Forms | Version: 1.7-rc-1
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Ready for checkin
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Erik Romijn <eromijn@…>):
In [changeset:"307eef20e35e78b1e812dc347c6c959e380267cf"]:
{{{
#!CommitTicketReference repository=""
revision="307eef20e35e78b1e812dc347c6c959e380267cf"
[1.7.x] Fixed #23075 -- Added documentation on novalidate attribute and
made it default for admin
Backport of cbdda28208c9c2aea479d5a482ff27bf37869d34 from master.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23075#comment:12>