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

[Jonathan Lu]

Hi Pavel,

I've filed bug 7198816 for this problem,

http://bugs.sun.com/view_bug.do?bug_id=7198816

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