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

[Jing Lv]

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?

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