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

[Jonathan Lu]

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.
Any comments on the patch?

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