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.

[Ryan J Ollos]

Committed to 1.0-stable in [11994:11995]. Merged to trunk in [11996].

[Jun Omae]

Sorry for my late response.

When clicking "Preview page" on wiki editor, #info (Change information for future version …) block is scrolled to top. However, after r11995, textarea is scrolled to top caused by $(".trac-focus").focus() on Firefox.

[Ryan J Ollos]

Thank you for testing and finding that issue. I've proposed the simple fix of not setting the focus when in preview or review mode, but let me know if you see a better way. The changes can be found in rjollos.git:t11084.2, along with two small refactorings.

[Jun Omae]

I found the workaround to avoid it calling $.scrollToTop with setTimeout(..., 1). Also, I've added trac-scroll class which a element is scrolled to top on document ready. See [a4166f0c5/jomae.git].

[Ryan J Ollos]

I like the trac-scroll class. For the case of Preview or Review changes of a wiki page, we are potentially setting the focus to an element that is not visible on the page. Maybe this is okay though, since a keypress will scroll the page to the top of the element.

[Ryan J Ollos]

Reopening, just so that we don't forget about the fix needed here.

[Ryan J Ollos]

Maybe we should rename trac-focus to trac-autofocus, since the HTML5 attribute of similar functionality is named ​autofocus? I think it would be okay to make this change since the changes in this ticket haven't been included in a release yet.

I've started some reading lately on HTML5, and it sounds like we can't use new HTML5 attributes and remain XHMTL compliant (specifically, XHTML 1.0 compliant). Has anyone given thought to the future of Trac with regard to utilization of HTML5 features?

[Jun Omae]

Maybe we should rename trac-focus to trac-autofocus, since the HTML5 attribute of similar functionality is named ​autofocus?

Sounds good.

[Ryan J Ollos]

Committed to 1.0-stable in [12338] and merged to runk in [12339].