Opened 14 years ago

Closed 14 years ago

#4088 closed defect (fixed)

FilteringSelect: Invalid Focus if use the select list

Reported by: ptbrunet Owned by: haysmark
Priority: high Milestone: 1.0
Component: Accessibility Version: 0.9
Keywords: Cc: [email protected]
Blocked By: Blocking:


Using the inline test case tab down to the FilteringSelect; press backspace enough times to get a popup list with more than one entry, choose a value and press enter. Focus should be on the closed "inline" object, but if you press tab or shift tab you can tell it's not there because the next tab stop is at some unexpected place, e.g. pressing tab goes to the first widget, pressing shift+Tab goes to the last widget so the focus is probably on the "document".

BTW, To see the failure the list has to have more than one item in the list, i.e. you have to backspace far enough so the list contains more than one entry.

Change History (10)

comment:1 Changed 14 years ago by ptbrunet

Regarding the comment about the list having to have more than one entry... The list can have more than one entry and if you select the item that is already in the text box there is no problem. It's only when you choose a new item.

comment:2 Changed 14 years ago by bill

Owner: set to haysmark

Which browser is this? On IE clicking something with a tabIndex blurs whatever is focused so need to refocus on the <input> box but I thought we were already doing that. By "choose" did you mean "click" or using the keyboard to pick?

comment:3 Changed 14 years ago by bill

Component: DijitAccessibility

comment:4 Changed 14 years ago by bill

Summary: Invalid Focus if use the select list in a FilteringSelectFilteringSelect: Invalid Focus if use the select list

comment:5 Changed 14 years ago by ptbrunet

Cc: [email protected] added; ptbrunet removed

comment:6 Changed 14 years ago by haysmark

The InlineEditBox? doesn't get focus when the FilteringSelect? value actually changes. That's why you needed the full menu so you could change the value.

Not that I know where the focus is going yet.

comment:7 Changed 14 years ago by bill

Hmm, I thought that InlineEditBox? monitored onChange events in the editor at which point it closed the editor (in this case, the FilteringSelect?) and returned focus to the rendering code. It doesn't seem like this is related to FilteringSelect?.

comment:8 Changed 14 years ago by haysmark

This is the problem of closing onChange vs closing on enter. FilteringSelect? fires onChange before on enter, so the on enter code never executes because the InlineEditBox? is already closed by onChange. If you choose the same menu option like pete says, onChange isn't fired so the on enter code fires (because InlineEditBox? is still open) and you see the focus happen.

It's inappropriate to focus onChange (user might have clicked away) so there is no focus code in onChange.

In the case of FilteringSelect?, we really want the on enter to reach InlineEditBox? before onChange.

comment:9 Changed 14 years ago by haysmark

Status: newassigned

comment:10 Changed 14 years ago by Douglas Hays

Resolution: fixed
Status: assignedclosed

(In [10492]) Fixes #4088. Proxy commit for haysmark. Changed _onChange and save so that InlineEditBox? focuses onChange when the user presses Enter and still does not focus when the user clicks away.

Note: See TracTickets for help on using tickets.