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