This is the simplest way to reproduce it: [X] choice A [text input (maybe enabled when choice A is selected, to enter further info)] [ ] choice B [other controls]
In this situation, when tab goes like this: choice A -> text input -> choice A -> .... (no way to reach other controls). This is because focus manager, focusing away from the text input, find choice B, see that is part of a group, and move focus to selected element of the group, even if it is actually *before* the current focus. IMO, it should check for this condition. 2013/9/20 Cosma Colanicchia <cosma...@gmail.com> > Absolutely, but if there are other controls "interleaved" with the radio > buttons of the same group, when the focus leave this interleaved components > the focus is "moved back" to the selected button... even if this is > "before" in the computed tab loop, actually creating a closed tab loop that > is impossible to escape without using the mouse. > > > > > 2013/9/20 Alex Harui <aha...@adobe.com> > >> The default behavior on Windows is/was that you tab to a group of radio >> buttons which will focus the selected one or the first one if none are >> selected, then use arrow keys to move between them. Another tab moves you >> to the next/previous control or group. >> >> The Flex FocusManager attempts to replicate that behavior. Is that what >> you are seeing? >> >> -Alex >> >> On 9/20/13 7:08 AM, "Cosma Colanicchia" <cosma...@gmail.com> wrote: >> >> >Hi list, maybe I found an issue with keyobard focus manager. >> >I have a situation like this (hope you get the pic): >> > >> > >> >[previous controls] >> >[radio A] [radio B] >> > [radio A1] [radio B1] [text input] >> > [radio A2] [radio B2] >> >[next controls] >> > >> > >> >Now, the tab focus management is completely broken: >> > - when focus is on [radio A2], tab go back to [radio A] - there's no way >> >to move to [next controls] >> > - when focus is on [text input], tab go back to [radio B1] - again, no >> >way >> >to move to [next controls] >> > >> > >> >I think that the bug is in the FocusManager.getIndexOfNextObject method: >> >when focus is on [radio A2], the next focus candidate is [radio B] (due >> to >> >containers visual layout), but it is part of a focus group, so the >> >FocusManager bring it to *the selected element of its focus group*, that >> >is >> >[radio A]. >> > >> >In my opinion, this should be done only if no other elements of the >> >same focus group have an index, in the focus candidate list, that is less >> >then the index of the current focused component, to avoid "moving back" >> >the >> >focus and creating closed tab loops (maybe reversing the index check when >> >moving focus backwards). >> > >> > >> > >> >The only workaround I found so far is structuring the containers so that >> >component belonging to the same focus group are kept adjacent, but it is >> >very difficult (if not impossible) to achieve the same visual output >> (e.g. >> >put [radioA] and [radioB] in a dedicated HGroup, ditto for [radio B1] and >> >[radio B2], trying to keep [text input] aligned to [radio B1] someway). >> > >> >Any thoughts on this? If I'm not missing something obvious, I'd like to >> >file an issue... >> >> >
