<Swing Dev> [Accessibility]Focus unable to traverse in the menubar
Frank Ding
dingxmin at linux.vnet.ibm.com
Wed Jan 23 03:00:27 UTC 2013
Hi Alexandr.
Thanks.
To swing-dev, seems I still need anther member review before
committing. Is there anybody who would like to review it?
Best regards,
Frank
On 1/22/2013 10:54 PM, Alexander Scherbatiy wrote:
> On 1/22/2013 9:21 AM, Frank Ding wrote:
>> 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.
>
> The fix looks good for me.
>
>> By the way, please let me know once 2401619 is migrated to the bug
>> system.
> I will let you know.
>
> Thanks,
> Alexandr.
>>
>> 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