flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: FocusManager issue with sparse focus groups
Date Fri, 20 Sep 2013 15:01:48 GMT
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?


On 9/20/13 7:08 AM, "Cosma Colanicchia" <cosmacol@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
>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
>[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"
>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...

View raw message