Return-Path: X-Original-To: apmail-flex-issues-archive@minotaur.apache.org Delivered-To: apmail-flex-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4031B10B6F for ; Fri, 4 Oct 2013 18:48:51 +0000 (UTC) Received: (qmail 9224 invoked by uid 500); 4 Oct 2013 18:48:48 -0000 Delivered-To: apmail-flex-issues-archive@flex.apache.org Received: (qmail 8988 invoked by uid 500); 4 Oct 2013 18:48:45 -0000 Mailing-List: contact issues-help@flex.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@flex.apache.org Delivered-To: mailing list issues@flex.apache.org Received: (qmail 8922 invoked by uid 99); 4 Oct 2013 18:48:44 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Oct 2013 18:48:44 +0000 Date: Fri, 4 Oct 2013 18:48:44 +0000 (UTC) From: "Alex Harui (JIRA)" To: issues@flex.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (FLEX-33772) Incorrect tab focus behavior (closed loops) when using focus groups (such as RadioButton components) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/FLEX-33772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13786488#comment-13786488 ] Alex Harui commented on FLEX-33772: ----------------------------------- Ok, took a look at the new patch. Looks pretty good, thanks for figuring it out. I think I see your strategy, and I'm ok with it. There is one behavioral change: For 3 contiguous radiobuttons of which none are selected, If you shift-tab onto the 3rd one, the first one now gets selected. In the old behavior the 3rd one gets selected. I want to know more about the test cases in your comment on 9/23 where you say there is a "known limitation". This makes it sound like there some other behavioral change or bug. What is the scenario that exposes this limitation? We don't want to break existing apps just to fix this bug. Finally, it looks like you are adding another potentially full loop through all of the focusableCandidates. There is a call to isEnabledAndVisible in the loop which does a parent walk up the display list. Most folks probably won't feel it, but there could be extreme cases where folks would feel it. That's why I suggested detecting that there were non-contiguous radiobuttons and this loop is needed, so everyone wouldn't be prone to any potential performance issues from this loop. > 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 > 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 (v6.1#6144)