<AWT Dev> [7u10] Review request for 6981400 Tabbing between textfield do not work properly when ALT+TAB
artem.ananiev at oracle.com
Tue Sep 25 06:44:40 PDT 2012
the fix looks a little bit scary, but I don't see a way to make it
better, simpler, or safer. So approved.
On 9/7/2012 1:57 PM, Anton V. Tarasov wrote:
> Please review a fix for the CR:
> It's almost identical to the fix pushed to jdk8 recently. The only small
> difference is here:
> 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:
More information about the awt-dev