flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cosma Colanicchia <cosma...@gmail.com>
Subject Re: FocusManager issue with sparse focus groups
Date Fri, 20 Sep 2013 15:10:46 GMT
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 <cosmacol@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 <aharui@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" <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
>> >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...
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message