flex-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Harui (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLEX-33772) Incorrect tab focus behavior (closed loops) when using focus groups (such as RadioButton components)
Date Thu, 03 Oct 2013 19:20:50 GMT

    [ https://issues.apache.org/jira/browse/FLEX-33772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13785457#comment-13785457
] 

Alex Harui commented on FLEX-33772:
-----------------------------------

Sorry I didn't look at this sooner.  There appears to be a lot of whitespace changes in the
patch that makes it difficult to see what you changed.  The standard at Apache Flex is 4-space
indentation in AS code.  Please submit a new patch that preserves as much of the whitespace
as possible.

Note also that I probably won't accept a patch that changes current behavior.  There are several
cases to consider:
1) tabbing into a group where no control in the group is selected.  In this case the control
that is first or last (depending on tab or shift-tab gets focus.
2) tabbing into a group where a control is selected.  The selected control must always get
focus.
3) tabbing out of a group regardless of what is selected.  Focus should not go to any other
control in the group.

First, let's agree that this should be the behavior when the all controls in the group are
contiguous.  If we can agree on that, how should this behavior change if the group is not
contiguous?  For the example:

checkbox
radio1_group1
   TextInput1
radio2_group1
   TextInput2
radio3_group1
   TextInput3
numericstepper

I think it should be:

1) tabbing into a group where no control is selected.  In theory this behavior should not
change.  The controls that appear subordinate to the last member of the group (i.e. TextInput3)
should already focusable via shift-tab so when you finally come upon a group member it should
be in the right order regardless of what direction you are tabbing.
2) tabbing into a group where a control is selected.  I think that if forward tabbing from
the checkbox and radio2 is selected that focus goes to radio2 and skip radio1 and TextInput
1.
3) This is the main case you want to change.  When focus is on a radiobutton, the tab goes
to the next TextInput.

But now we need one more case:
4) If focus is on a TextInput2 and radio2 is selected, where does focus go on the next Tab?
 The FocusManager today would put focus on radio2 because it would find radio3 and realize
that radio2 is the selected member of the group.  Where do you want focus to go?  To TextInput3,
radio3 or the numericstepper?

Once we agree on that, then we can determine what code needs to change.

In theory, the code should determine if the group is contiguous and then jump to a different
code path if it isn't.  That would likely have the least impact on current behavior.  I think
the contiguous test is simple.  All members of the group should be together in the focusableCandidates
array otherwise they are not contiguous.

> Incorrect tab focus behavior (closed loops) when using focus groups (such as RadioButton
components)
> ----------------------------------------------------------------------------------------------------
>
>                 Key: FLEX-33772
>                 URL: https://issues.apache.org/jira/browse/FLEX-33772
>             Project: Apache Flex
>          Issue Type: Bug
>          Components: Focus Manager
>    Affects Versions: Apache Flex 4.11.0
>            Reporter: Cosma Colanicchia
>            Priority: Minor
>              Labels: patch
>         Attachments: FocusManager.patch, TestFocus.mxml, TestFocus-screenshot.png
>
>
> When additional components that are not part of the focus group are positioned between
two group elements, it may be impossible to move the focus away from the group using the keyboard.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message