<Swing Dev> Approved: [Accessibility]Focus unable to traverse in the menubar
Alexander Scherbatiy
alexandr.scherbatiy at oracle.com
Thu Feb 7 14:16:44 UTC 2013
Hi Frank,
I am sorry. I have committed the fix and forgot to add you as the
author.
I could propose you the issue 8007716 that should be easy to fix.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007716
The issue may not be available on the bugs.sun.com yet but all
details can be found in the email:
http://mail.openjdk.java.net/pipermail/swing-dev/2013-February/002535.html
It needs to add the FunctionalInterface annotation to some swing
interfaces for the lambda integration.
The javax.print and javax.imageio packages should be excluded from
the list because they be handled by the Java 2D team.
Thanks,
Alexandr.
On 2/6/2013 7:05 AM, Frank Ding wrote:
> Hi SAM,
> Thank you.
>
> Best regards,
> Frank
> On 2/5/2013 6:20 PM, Sergey Malenkov wrote:
>> Hi Frank,
>>
>> I approve.
>>
>> Thanks,
>> SAM
>>
>> On 23.01.2013 7:00, Frank Ding wrote:
>>> 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