<Swing Dev> [Accessibility]Focus unable to traverse in the menubar
Alexander Scherbatiy
alexandr.scherbatiy at oracle.com
Mon Jan 21 10:02:05 UTC 2013
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