Opened 11 years ago

Closed 11 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: [email protected]
Blocked By: Blocking:


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:

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 11 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 11 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.