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

Frank Ding dingxmin at linux.vnet.ibm.com
Fri Jan 18 06:53:19 UTC 2013 

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?

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