<Swing Dev> [Accessibility]Focus unable to traverse in the menubar
Frank Ding
dingxmin at linux.vnet.ibm.com
Tue Jan 22 05:21:33 UTC 2013
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.
By the way, please let me know once 2401619 is migrated to the bug
system.
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