Bug when auto-focusing on field with MultiWidget in admin site

[rduffield]

The admin site JavaScript, when creating a new instance of a model with a DateTimeField, attempts to focus on an element that does not exist. Take this basic example:

class Reservation(models.Model):
    start_date = models.DateTimeField(blank=False, null=False)

This results in the use of the AdminSplitDateTime widget. The two respective HTML fields have IDs of id_start_date_0 and id_start_date_1. However, the JavaScript that is generated is:

document.getElementById("id_start_date").focus();

This fails, due to there not being an element on the page with an ID of id_start_date.

I tracked this down to the _auto_id method within the BoundField class. Creating the auto_id depends on the field's html_name; in the case outlined above, both fields have html_names of start_date. However, the rendering of a MultiWidget is such that the IDs are generated differently than normal widgets.

My naive patch introduces a new property on a BoundField called focus_id. The focus_id returns auto_id as before for all widgets that are not MultiWidgets. Otherwise, it returns the first element within a MultiWidget set. The admin change_form.html template now also takes advantage of this field. I did not want to change any logic within auto_id itself; this seemed a little more dangerous. :-)

[rduffield]

I have attached a test that reproduces this bug.

Note that I should have been more clear; this bug is only evident if the DateTime field is of course the first field rendered in the admin form.

[Collin Anderson]

Can we instead have the javascript find the first form element automatically and focus that?

[rduffield]

That certainly seems like a great alternative to me; I was simply trying to maintain what I figured was the convention.

[ales.zoulek@…]

focusing first active form element

[ales.zoulek@…]

I added a patch. Focusing first form field could not be as trivial at it seems. But it should work fine.

[Ales Zoulek]

updated the patch to first try it the old way and if it fails to fall back to for-loop.

[Jacob]

Pushing to 1.2: this is a UI issue which is annoying but doesn't impact usability.

[Colin Copeland]

update using jquery

[Colin Copeland]

alternative patch if #12627 is closed

[Colin Copeland]

Tested in:

• Mac: Safari 4.0.5, Firefox 3.6, Chrome 5.0.307.11 beta
• Windows: Internet Explorer 6.0.2800.1106

[James Bennett]

This is another ticket that's not really release-critical; pushing off the 1.2 milestone, and we'll likely hit it in 1.3 (which is being scheduled to focus on these sorts of minor-annoyance issues).

[Ramiro Morales]

#14364 and #14858 were also a duplicates, both proposed JS-based solutions.

[Ramiro Morales]

Alternate Python-based approach

[Ramiro Morales]

I've just attached a patch that, just like rduffield's patch, proposes solving this on the Python side by adding a property to django.forms.BoundField.

Difference is that it uses a strategy similar to the label_tag() method to make sure it returns a form ID usable for e.e. auto-focusing the field. The new property name is stable_field, for lack of a better name, can be changed if native English speakers deem necessary.

[Julien Phalip]

Ramiro, I like the approach in your patch. I've just updated it with a test for when the first field only has a single widget. I've also renamed the stable_id property to id_for_label, which may be a bit more versatile. Thanks!

[Russell Keith-Magee]

In [15452]:

Fixed #10573 -- Corrected autofocus problem in admin when the first widget displayed is a multiwidget. Thanks to rduffield for the report, and to Ramiro and Julien Phalip for the patch.

[Russell Keith-Magee]

In [15456]:

[1.2.X] Fixed #10573 -- Corrected autofocus problem in admin when the first widget displayed is a multiwidget. Thanks to rduffield for the report, and to Ramiro and Julien Phalip for the patch.

Backport of r15452 from trunk.

[Jacob]

Milestone 1.3 deleted