<Swing Dev> [Accessibility]Focus unable to traverse in the menubar

Alexander Scherbatiy alexandr.scherbatiy at oracle.com
Tue Jan 22 14:54:48 UTC 2013


On 1/22/2013 9:21 AM, Frank Ding wrote:
> Hi Alexandr,
>   Thanks for your information.  I have created a new webrev review @
> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.03/
>   Pls take a look.

        The fix looks good for me.

>   By the way, please let me know once 2401619 is migrated to the bug 
> system.
        I will let you know.

        Thanks,
        Alexandr.
>
> Best regards,
> Frank
>
> On 1/21/2013 6:02 PM, Alexander Scherbatiy wrote:
>> On 1/18/2013 10:53 AM, Frank Ding wrote:
>>> Hi Alexandr,
>>>   Could you please let me know if there is any update on review 
>>> result?  I did not receive any review information of 2401619 which 
>>> means it's still not public/reviewed yet, right?
>>      I got answers from the javadoc team:
>>       8000326
>>        The JMenuBar javadoc could be updated to
>>       -------------------------
>>       By default, pressing the Tab key does not transfer focus from a 
>> <code>JMenuBar</code> which is added to a container together with 
>> other Swing components, because the 
>> <code>focusTraversalKeysEnabled</code> property of 
>> <code>JMenuBar</code> is set to <code>false</code>. To resolve this, 
>> you should call the 
>> <code>JMenuBar.setFocusTraversalKeysEnabled(true)</code> method.
>>       -------------------------
>>
>>      2401619
>>         Yes, there should be "will return" expression instead of the 
>> "with return"?
>>          The 2401619 java incident has not been migrated yet to the 
>> bug system.
>>
>>     Thanks,
>>     Alexandr.
>>
>>
>>>
>>> Best regards,
>>> Frank
>>>
>>> On 12/18/2012 2:36 PM, Frank Ding wrote:
>>>> Thanks, Alexandr.
>>>>
>>>> On 12/14/2012 8:40 PM, Alexander Scherbatiy wrote:
>>>>> On 12/13/2012 1:01 PM, Frank Ding wrote:
>>>>>> Hi Alexandr,
>>>>>>   I made another change according to your comment @ 
>>>>>> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.02 . Please 
>>>>>> review it.
>>>>>>   I submitted a bug whose internal review ID is 2401619 about one 
>>>>>> wording mistake in ContainerOrderFocusTraversalPolicy. But since 
>>>>>> the bug system transition, newly submitted bugs cannot pass 
>>>>>> review and get publicly available.  Can you help me to have 
>>>>>> somebody review it?
>>>>>
>>>>>      I resent the both issues 8000326 and 2401619 to the JDK doc 
>>>>> team to review.
>>>>>
>>>>>      Thanks,
>>>>>      Alexandr.
>>>>>
>>>>>>
>>>>>>   Thanks and Best regards,
>>>>>>   Frank
>>>>>>
>>>>>> On 12/12/2012 10:07 PM, Alexander Scherbatiy wrote:
>>>>>>> On 12/10/2012 11:08 AM, Frank Ding wrote:
>>>>>>>> Hi Pavel,
>>>>>>>>   I think pointing out the special behavior in javadoc makes 
>>>>>>>> more sense.  Could you please take a look at my draft below?
>>>>>>>> http://cr.openjdk.java.net/~dingxmin/8000326/webrev.01
>>>>>>>      I think that It has more sense to point this special 
>>>>>>> behavior in the JMenuBar class itself.
>>>>>>>      It looks more naturally to read about the JMenuBar focus 
>>>>>>> traversal behaviour from the JMenuBar javadoc.
>>>>>>>
>>>>>>>>   Note that I think in the sentence "By default, methods of 
>>>>>>>> this class with return a Component only if it is" it should be 
>>>>>>>> "will" not "with", shouldn't it?
>>>>>>>      Thank you that you point it out. Could you create an issue 
>>>>>>> on it?
>>>>>>>
>>>>>>>     Thanks,
>>>>>>>     Alexandr.
>>>>>>>>
>>>>>>>>   Expecting your reply.
>>>>>>>> Best regards,
>>>>>>>> Frank
>>>>>>>>
>>>>>>>> On 10/8/2012 7:47 PM, pavel porvatov wrote:
>>>>>>>>> Hi Jonathan,
>>>>>>>>>> Hi Pavel,
>>>>>>>>>>
>>>>>>>>>> On 10/02/2012 11:31 PM, Pavel Porvatov wrote:
>>>>>>>>>>> Hi Jonathan,
>>>>>>>>>>>> Hi Pavel,
>>>>>>>>>>>>
>>>>>>>>>>>> I've filed bug 7198816 for this problem,
>>>>>>>>>>>>
>>>>>>>>>>>> Regards, Pavel
>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7198816
>>>>>>>>>>> This bug was not ported to jira, so I created another bug:
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8000326
>>>>>>>>>>
>>>>>>>>>> Thanks for porting, but I have trouble with opening that link.
>>>>>>>>> Sorry, use the following link:
>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000326
>>>>>>>>>
>>>>>>>>> but the bug is not available yet... It contains the same 
>>>>>>>>> description as the original bug.
>>>>>>>>>
>>>>>>>>>> Any comments on the patch?
>>>>>>>>> The fix looks dangerous for me. After the fix the 
>>>>>>>>> setFocusTraversalKeysEnabled method doesn't work for JMenuBar 
>>>>>>>>> (when ContainerOrderFocusTraversalPolicy is used) - it ignores 
>>>>>>>>> this property...
>>>>>>>>>
>>>>>>>>> Regards, Pavel
>>>>>>>>>>
>>>>>>>>>> best regards
>>>>>>>>>> Jonathan
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards, Pavel
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/09/2011 07:25 PM, Pavel Porvatov wrote:
>>>>>>>>>>>>> Hi Jing,
>>>>>>>>>>>>>> Thanks Pavel,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>      It seems fine to me, if no other 
>>>>>>>>>>>>>> suggestions/opinions, I guess we can move on with this?
>>>>>>>>>>>>> Yes, we can. Could you please file a bug for the problem 
>>>>>>>>>>>>> as well?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks, Pavel
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2011/11/2 19:58, Pavel Porvatov wrote:
>>>>>>>>>>>>>>> Hi Jing,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hello Anton,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     Thanks for the review. I am still trying to figure 
>>>>>>>>>>>>>>>> out some real case and provide more detail the customer 
>>>>>>>>>>>>>>>> may fail.
>>>>>>>>>>>>>>>>     Anyway, I agree we'd better update the java spec to 
>>>>>>>>>>>>>>>> make it clear for the customers. I'd like to know if 
>>>>>>>>>>>>>>>> anyone can help with that?
>>>>>>>>>>>>>>> I'm not sure that javadoc changing is a good decision in 
>>>>>>>>>>>>>>> this case. ContainerOrderFocusTraversalPolicy is 
>>>>>>>>>>>>>>> designed for AWT, but I don't know why that policy 
>>>>>>>>>>>>>>> cannot be used for Swing components as well. I see 
>>>>>>>>>>>>>>> several problems:
>>>>>>>>>>>>>>> 1. We cannot change javadoc of 
>>>>>>>>>>>>>>> ContainerOrderFocusTraversalPolicy because of backward 
>>>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>>>> 2. We cannot remove setFocusTraversalKeysEnabled(false) 
>>>>>>>>>>>>>>> from the JMenuBar#JMenuBar() constructor because of 
>>>>>>>>>>>>>>> backward compatibility
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> May be the best decision is to specify, that JMenuBar 
>>>>>>>>>>>>>>> creates menu with the focusTraversalKeysEnabled = false
>>>>>>>>>>>>
>>>>>>>>>>>> Did you mean that for the new menu 
>>>>>>>>>>>> setFocusTraversalKeysEnabled(false) ? I've tried, but it 
>>>>>>>>>>>> does not seem to work for this problem.
>>>>>>>>>>>>
>>>>>>>>>>>>  if my understanding is incorrect, please help to fix me.
>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards, Pavel
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2011/10/12 20:54, Anton Tarasov wrote:
>>>>>>>>>>>>>>>>> Hi Neil,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 10/10/2011 7:01 PM, Neil Richards wrote:
>>>>>>>>>>>>>>>>>> On Mon, 2011-10-10 at 16:56 +0400, Anton Tarasov wrote:
>>>>>>>>>>>>>>>>>>> Hi Neil and Jing,
>>>>>>>>>>>>>>>>>>> I'm afraid that it's wrong to use 
>>>>>>>>>>>>>>>>>>> ContainerOrderFocusTraversalPolicy
>>>>>>>>>>>>>>>>>>> for swing components. This policy is designed for AWT.
>>>>>>>>>>>>>>>>>>> JMenuBar calls setFocusTraversalKeysEnabled(false) 
>>>>>>>>>>>>>>>>>>> in its ctor which
>>>>>>>>>>>>>>>>>>> means that it "swallows" focus traversal keys (like 
>>>>>>>>>>>>>>>>>>> TAB/SHIFT-TAB
>>>>>>>>>>>>>>>>>>> etc.)
>>>>>>>>>>>>>>>>>>> and so it can't be a member of a focus traversal 
>>>>>>>>>>>>>>>>>>> chain. Swing's
>>>>>>>>>>>>>>>>>>> default traversal policy 
>>>>>>>>>>>>>>>>>>> (LayoutFocusTraversalPolicy) excludes
>>>>>>>>>>>>>>>>>>> JMenuBar
>>>>>>>>>>>>>>>>>>> from a focus traversal cycle. 
>>>>>>>>>>>>>>>>>>> ContainerOrderFocusTraversalPolicy is
>>>>>>>>>>>>>>>>>>> not "aware" about JMenuBar and so it allows it.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So, either a default Swing policy should be used, or 
>>>>>>>>>>>>>>>>>>> a custom policy.
>>>>>>>>>>>>>>>>>>> At worst, ContainerOrderFocusTraversalPolicy should 
>>>>>>>>>>>>>>>>>>> be overriden
>>>>>>>>>>>>>>>>>>> to exclude JMenuBar from a cycle (override its 
>>>>>>>>>>>>>>>>>>> accept(Component)
>>>>>>>>>>>>>>>>>>> method).
>>>>>>>>>>>>
>>>>>>>>>>>> I agree that backward compatibility should not be broken by 
>>>>>>>>>>>> the fix, so here's a patch from me for the worst case, 
>>>>>>>>>>>> could you please help to take a look?
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7198816/
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>> Anton.
>>>>>>>>>>>>>>>>>> Hi Anton,
>>>>>>>>>>>>>>>>>> Thanks for reviewing the suggestion, and for your 
>>>>>>>>>>>>>>>>>> insights into this
>>>>>>>>>>>>>>>>>> scenario.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> > From the Javadoc, it seems that 
>>>>>>>>>>>>>>>>>> setFocusTraversalKeysEnabled() is mainly
>>>>>>>>>>>>>>>>>> concerned with choosing whether focus traversal key 
>>>>>>>>>>>>>>>>>> presses (normally
>>>>>>>>>>>>>>>>>> TAB and SHIFT-TAB) are processed "automatically" 
>>>>>>>>>>>>>>>>>> (when 'true') or are
>>>>>>>>>>>>>>>>>> delivered to the Component as key events (for the 
>>>>>>>>>>>>>>>>>> component's code to
>>>>>>>>>>>>>>>>>> process "manually").
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> (In the case of JMenuBar, it makes them come through 
>>>>>>>>>>>>>>>>>> as key events, but
>>>>>>>>>>>>>>>>>> doesn't do anything special to process these events, 
>>>>>>>>>>>>>>>>>> which is why they
>>>>>>>>>>>>>>>>>> get discarded.)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That is right, though it doesn't directly relate to 
>>>>>>>>>>>>>>>>> the issue we're talking about =)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Your description above, though, seems to suggest that 
>>>>>>>>>>>>>>>>>> it is generally
>>>>>>>>>>>>>>>>>> undesirable for the JMenuBar to be given the focus, 
>>>>>>>>>>>>>>>>>> as all the
>>>>>>>>>>>>>>>>>> Swing-aware focus traversal policies make a point of 
>>>>>>>>>>>>>>>>>> not giving focus to
>>>>>>>>>>>>>>>>>> JMenuBar items.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If this is so, then wouldn't it make sense to call 
>>>>>>>>>>>>>>>>>> setFocusable(false)
>>>>>>>>>>>>>>>>>> from its constructor (too), to ensure it doesn't get 
>>>>>>>>>>>>>>>>>> focus ?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Or, to put it another way, could you explain a little 
>>>>>>>>>>>>>>>>>> of the reasoning
>>>>>>>>>>>>>>>>>> or scenario behind why it is desirable for JMenuBar 
>>>>>>>>>>>>>>>>>> items to be
>>>>>>>>>>>>>>>>>> generally focusable, even though they aren't 
>>>>>>>>>>>>>>>>>> focus-traversable ?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I think such an explanation would be really helpful 
>>>>>>>>>>>>>>>>>> in clearing up my
>>>>>>>>>>>>>>>>>> confusion on this point.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks, Neil
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Well, I suspect that the core of the problem is that 
>>>>>>>>>>>>>>>>> adding JMenuBar as JComponent to a swing
>>>>>>>>>>>>>>>>> container doesn't make much sense. Though it is not 
>>>>>>>>>>>>>>>>> directly prohibited, doing so may cause
>>>>>>>>>>>>>>>>> side effects like the one you've discovered. When 
>>>>>>>>>>>>>>>>> JMenuBar is set properly onto a JFrame its focus
>>>>>>>>>>>>>>>>> is managed by JRootPane and its focusability just 
>>>>>>>>>>>>>>>>> isn't taken into account. That's may be the reason
>>>>>>>>>>>>>>>>> it's not declared unfocusable. Honestly, I can't tell 
>>>>>>>>>>>>>>>>> you exactly.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If you do it, you probably won't make any harm, but I 
>>>>>>>>>>>>>>>>> personally don't think this is a vital fix
>>>>>>>>>>>>>>>>> (unless you have a good use case of the scenario 
>>>>>>>>>>>>>>>>> you've provided). Anyway, this is a swing question
>>>>>>>>>>>>>>>>> (I'm, as an AWT dev member, leaving the decision to 
>>>>>>>>>>>>>>>>> swing guys).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Anton.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>




More information about the swing-dev mailing list