Opened 9 years ago

Closed 9 years ago

#11776 closed enhancement (wontfix)

Unexpecting tab behaviour when switching to widgets that just have been disabled/enabled

Reported by: viktor.h Owned by: Douglas Hays
Priority: low Milestone: tbd
Component: Dijit Version: 1.5
Keywords: tab focus disable widget Cc: viktor@…
Blocked By: Blocking:

Description

Consider an input widget with an onChange or onBlur handler, and two buttons (Save/Cancel?) next to it. For a "Save" operation, the input widget may not be empty. Thus, the first button (Save) shall be enabled or disabled by the handler.

I tried to create a small testcase: http://www.steckenpferde.de/tmp/dijit-tabbing.html

Type at least one character into the Textarea, then press <TAB>. The first button gets activated, but the focus is on the second button: probably it has been determined as the next tab target before the handler ran.

The problem works backwards as well. Remove the text from the Textarea, then press <TAB> again. You have now focus on the disabled widget.

This happens in Iceweasel/Firefox? 3.5.11 as well as in Chromium 6.0.472.53.

I did find a workaround (by manually setting the focus in the handlers), but I wanted to report this behaviour in case you want to improve it. Maybe delaying the determination of the next tab target until after onChange / onBlur has run, or a new handler designed to run before focusing comes into play?

Change History (2)

comment:1 Changed 9 years ago by bill

Owner: set to Douglas Hays

Hmm, well the browser determines the tabbing target, not dojo (and we don't want to change that). But perhaps we could catch the TAB keypress event and validate the widget (without calling dojo.stopEvent()) so that the validation happens earlier. Of course that wouldn't do anything for mouse users, so for them, we still need to catch the onBlur event and validate the widget.

Doug, what do you think?

comment:2 Changed 9 years ago by Douglas Hays

Resolution: wontfix
Status: newclosed

I don't think that we want to try and add complexity and change the browser tabbing order. Adding intermediateChanges:true seems to solve the user's issue.

Note: See TracTickets for help on using tickets.