Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Received-SPF: pass (athena.apache.org: domain of cosmacol@gmail.com designates
 209.85.223.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CA+W8zUPY4pUNYm+hQiUa-p1emEhrftny91jEYHSR5T=4fO=UWQ@mail.gmail.com>
References: 
 <CA+W8zUOdxWvSUNjr7mhoPdB888HELnm23xhh4Ug-ur2E-Qmwow@mail.gmail.com>
 <CE61B0C5.1387E%aharui@adobe.com>
 <CA+W8zUPY4pUNYm+hQiUa-p1emEhrftny91jEYHSR5T=4fO=UWQ@mail.gmail.com>
From: Cosma Colanicchia <cosmacol@gmail.com>
Date: Fri, 20 Sep 2013 17:10:46 +0200
Message-ID: 
 <CA+W8zUOA3Yt+FUsywmiYFHyPm+GXTV-ixrRdnCH8gU1sign4Fg@mail.gmail.com>
Subject: Re: FocusManager issue with sparse focus groups
To: Apache Flex Developers ML <dev@flex.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2fac06976df04e6d214fa

--001a11c2fac06976df04e6d214fa
Content-Type: text/plain; charset=UTF-8

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

--001a11c2fac06976df04e6d214fa--