Edgewall Software
Modify

Opened 6 years ago

Closed 5 years ago

#11084 closed enhancement (fixed)

Edit pages should put focus on text input element

Reported by: Ryan J Ollos Owned by: Ryan J Ollos
Priority: low Milestone: 1.0.2
Component: general Version: 1.0-stable
Severity: minor Keywords: jquery focus css
Cc:
Release Notes:

All edit and rename pages put the focus on the first input element on the page.

API Changes:

The trac-autofocus class can be added to an element to give it focus when the page loads. The trac-scroll class can be used to scroll to an id the page loads.

Description (last modified by Ryan J Ollos <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.

Attachments (0)

Change History (15)

comment:1 Changed 6 years ago by Ryan J Ollos <ryan.j.ollos@…>

Description: modified (diff)
  • 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.

comment:2 in reply to:  description Changed 6 years ago by 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.

comment:3 in reply to:  1 Changed 6 years ago by Christian Boos

Keywords: css added
Milestone: 1.0.2

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?

Yes, we'll have to try out.

comment:4 Changed 5 years ago by Ryan J Ollos

Owner: set to Ryan J Ollos
Reporter: changed from Ryan J Ollos <ryan.j.ollos@…> to Ryan J Ollos
Status: newassigned

comment:5 Changed 5 years ago by Ryan J Ollos

API Changes: modified (diff)
Release Notes: modified (diff)

Changes prepared in rjollos.git:t11084.

comment:6 Changed 5 years ago by Ryan J Ollos

Resolution: fixed
Status: assignedclosed

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

comment:7 Changed 5 years ago by 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.

comment:8 Changed 5 years ago by 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.

comment:9 Changed 5 years ago by 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].

comment:10 Changed 5 years ago by 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.

comment:11 Changed 5 years ago by Ryan J Ollos

Resolution: fixed
Status: closedreopened

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

comment:12 Changed 5 years ago by 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?

comment:13 Changed 5 years ago by Ryan J Ollos

Status: reopenedassigned

comment:14 in reply to:  12 Changed 5 years ago by Jun Omae

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

Sounds good.

comment:15 Changed 5 years ago by Ryan J Ollos

API Changes: modified (diff)
Resolution: fixed
Status: assignedclosed

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Ryan J Ollos.
The resolution will be deleted.
to The owner will be changed from Ryan J Ollos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.