flex-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cosma Colanicchia (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLEX-33772) Incorrect tab focus behavior (closed loops) when using focus groups (such as RadioButton components)
Date Fri, 04 Oct 2013 22:44:43 GMT

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

Cosma Colanicchia commented on FLEX-33772:

Thanks for reviewing the patch, Alex.

About the behavioral change, it could be easily fixed in the pre-loop code that is setting
the groupElementToFocus value.
However, that is exactly the additional loop you were talking about: I wasn't aware of the
performance implications of the isEnabledAndVisible call. The additional cycle was meant to
improve code readability (reducing in advance the "no selection in group" case and exposing
an explicitly named variable), but the code can be reworked to perform that logic directly
in the main loop if we want to optimize it. Actually, after this rework, I think that performance
will be slightly improved due to the fact that the patched implementation starts cycling focusables
from the current focused element and proceed in the direction of the tab movement (instead
of a fixed 0->length-1 focusable cycle of the current implementation), maximizing the chances
of finding the correct focus element with very few iterations.

About the doubts I was talking about in my previous comment:

1) what should happens when elements of two different groups are interleaved?
The patched implementation is simply skipping them, but this could make some element unreachable
in this (probably unlikely) situation. I have not analyzed the behavior of the current implementation,
but it doesn't look like it was doing anything special to handle it. What is the desiderated
behavior anyway? Should we try to move focus to the selected element of the 2nd group? But
this would mean a recursive behavior, and maybe the risk of generating an infinite recursion
(unless the new "only-forward/only-backward" cycle approach is enough to always avoid it).

2) I'm not 100% sure of the meaning of the check on the tabIndex.. it seems that manually
setting a different tabIndex of a group element should prevent focus to be automatically assigned
to it due to it being the selected one? What is the recursive call to the getIndexOfNextObject
itself supposed to accomplish in this case? I tried to keep this behavior in place in the
patched code, but I admit that I don't fully understand it.

> Incorrect tab focus behavior (closed loops) when using focus groups (such as RadioButton
> ----------------------------------------------------------------------------------------------------
>                 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
>            Assignee: Alex Harui
>            Priority: Minor
>              Labels: patch
>         Attachments: FocusManager.patch, FocusManager.patch, TestFocus-current.air, TestFocus.mxml,
TestFocus-patched.air, TestFocus-screenshot.png, TestFocus-updated.mxml
> 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

View raw message