id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
10573	Bug when auto-focusing on field with MultiWidget in admin site	rduffield	Colin Copeland	"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.  :-)
"		closed	contrib.admin	dev		fixed		ales.zoulek@…	Ready for checkin	1	0	0	0	0	0