Edit pages should put focus on text input element

[Ryan J Ollos]

Several pages put the focus in "the right place" on page load, allowing someone to immediately start entering text without a lot of tabbing or using the mouse. The following pages do that well:

• New Ticket: Summary text input gets focus.
• Milestone edit: Name text input gets focus.
• Search: Search text input gets focus.

Here's is a check of the places that jQuery's focus is used, not including JavaScript files such as query.js:

(t11081)user@debian-wheezy:~/Workspace/t11081$ grep -R --exclude-dir=.svn --exclude-dir=js ".focus()" trac-1.0-stable
trac-1.0-stable/trac/ticket/templates/milestone_edit.html:        $("#name").get(0).focus()
trac-1.0-stable/trac/ticket/templates/ticket.html:        $("#field-summary").focus();
trac-1.0-stable/trac/search/templates/search.html:      jQuery(document).ready(function($) {$("#q").get(0).focus()});

Here are some other places I'd like to see a text input or textarea have focus on page load:

• Wiki edit: Wiki textarea
• Wiki rename: New name text input
• Admin Component/Milestone/Enum/Version/Repository edit: Name text input
• Report edit: Title text input

The above cases feel like obvious candidates for this change. We could implement it more widely, for instance when navigating to the Admin General page, the Project Name input text field could be given focus. I don't like that as much since Admin General is not an edit page, rather a combination edit/view page. It seems like that change make unintended edits more likely. For example, a key slip and Project Name gets changed without the user noticing, and then they proceed to make their desired change, saving both (though a more verbose info message as shown in comment:8:ticket:11076 could help).

The ticket comment box seems like the most reasonable place to put the focus on the Ticket page, however for a typical ticket it won't be in the visible area on page load, so I've not set any element to have focus when the ticket page load.

Patch against 1.0-stable is forthcoming.

[Ryan J Ollos <ryan.j.ollos@…>]

• In ​bf4c4fe4, I've tried to incorporate some of the ideas in comment:4:ticket:11056. Rather than specifying a selector by id, the element that should have focus on page load is given the trac-focus class.
  • $("selector").get(0).focus() and $("selector").focus() were both used in the Trac code base. It doesn't seem to be necessary to get the DOM object before setting focus; according to the jQuery documentation for ​focus, focus can operate on a jQuery object. I read some threads that seemed to suggest that the former may have been necessary earlier in the life of jQuery.
• In ​59a8df25, I moved the $("trac-focus").focus() call to layout.html. This eliminates the need to include jQuery code in several templates and reduces code duplication. This will also allow plugins to take advantage of the trac-focus class without adding any jQuery code.
• In ​dbbb4fc6, the focus is set for several other admin pages and the attachment page. This is experimental; I'm less confident that these changes make sense, but seeking feedback.

[Christian Boos]

Replying to Ryan J Ollos <ryan.j.ollos@…>:

[…] The ticket comment box seems like the most reasonable place to put the focus on the Ticket page, however for a typical ticket it won't be in the visible area on page load, so I've not set any element to have focus when the ticket page load.

Right, for a ticket there's really just too many things you could want to do besides adding a comment. Even when you click on the Modify link, you still have the possibility to edit the description, or changing a field, or anything else. So it's fine to leave the ticket page as it is w.r.t. to the focus.

[Christian Boos]

Replying to Ryan J Ollos <ryan.j.ollos@…>:

• In ​bf4c4fe4, I've tried to incorporate some of the ideas in comment:4:ticket:11056. Rather than specifying a selector by id, the element that should have focus on page load is given the trac-focus class. […]
• In ​59a8df25, I moved the $("trac-focus").focus() call to layout.html. […]

Those two look like a good move forward. I'll wait a bit before integrating, in case Rémy has a word to say on the topic. In the meantime we could think about a place where such things would be document. A CSS usage chapter in the ApiDocs?

• In ​dbbb4fc6, […] seeking feedback.

Yes, we'll have to try out.

[Ryan J Ollos]

Changes prepared in rjollos.git:t11084.