Hi,
Please review a fix for the CR:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6981400
Webrev:
http://cr.openjdk.java.net/~ant/6981400.7u10/webrev.0/
It's almost identical to the fix pushed to jdk8 recently. The only small
difference is here:
http://cr.openjdk.java.net/~ant/6981400.7u10/webrev.0/src/macosx/classes/sun/lwawt/LWWindowPeer.java.sdiff.html
In the dispatchKeyEvent method, LWKeyboardFocusManagerPeer is retrieved
by passing an AppContext instance.
In jdk8 LWKeyboardFocusManagerPeer was refactored (CR 7124375).
Below I'm quoting the description of the fix for jdk8:
<<The fix covers a number of issues and is an evaluated version of the
fix originally integrated into jdk6. The scenario which reproduces
the referred problems looks pretty like the following:
A frame with components. The first component is focused. In its
focusLost(..) listener it performs some lengthy operation.
TAB key is pressed, say, 5 times. The first component loses focus, the
lengthy operation begins which freezes EDT for a while.
At the same time, a user switches to some other window by Alt-TAB and
then switches back by another Alt-TAB. When the lengthy
operation is done, the user expects focus to be transferred through the
components in order as if no toplevel switch has happened.
Alternatively, the toplevel switch could be done by a mouse click in a
component of the other java toplevel and then by a click to the
title of the original frame.
This may cause the following unexpected results:
1) Focus doesn't go through all the 5 components (which 5 TABs should
result in) but stops on, say, the 3rd one.
2) Components are being transferred in wrong order, say 2, 3, 2, 4, 5, 6 instead of 2, 3, 4, 5, 6.
3) A menu of the original frame eventually gets activated (reproducible on MS
Windows).>>
More details can be found here:
http://mail.openjdk.java.net/pipermail/awt-dev/2012-August/003421.html
Thanks,
Anton.
