<AWT Dev> [8] Review request for 6981400 Tabbing between textfield do not work properly when ALT+TAB

[Anton V. Tarasov]

Had to adopt the changes in LWWindowPeer.java to the latest changes in jdk:

http://cr.openjdk.java.net/~ant/6981400/webrev.7/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html

The changes are inessential, still the last webrev is this:

http://cr.openjdk.java.net/~ant/6981400/webrev.7

Thanks,
Anton.

On 8/30/12 2:54 PM, Artem Ananiev wrote:
>
> Approved.
>
> Thanks,
>
> Artem
>
> On 8/29/2012 2:48 PM, Anton V. Tarasov wrote:
>> Please look at the updated version:
>>
>> http://cr.openjdk.java.net/~ant/6981400/webrev.6
>>
>> It contains the following changes:
>>
>> 1.
>> http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java.udiff.html 
>>
>>
>> Comments updated.
>>
>> 2.
>> http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/java/awt/Component.java.udiff.html 
>>
>>
>> The method:
>>
>> ((MouseEvent)currentEvent).getComponent()
>>
>>
>> is called instead of getSource() in order to avoid "instanceof" check
>> for non-component sources.
>>
>> 3.
>> http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/sun/awt/SunToolkit.java.udiff.html 
>>
>>
>> AppContext is used to store window deactivation times to guarantee 
>> security.
>>
>> 4.
>> http://cr.openjdk.java.net/~ant/6981400/webrev.6/test/java/awt/Focus/6981400/Test1.java.html 
>>
>>
>> Focus events order check is suppressed for XToolkit where this
>> functionality can't be implemented due to time-less native focus 
>> messages.
>>
>> Thanks,
>> Anton.
>>
>> On 05.07.2012 18:30, Anton V. Tarasov wrote:
>>> [I had to fix the links in the previous e-mail, replaced webrev.4 with
>>> webrev.5, sorry]
>>>
>>> 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/webrev.5
>>>
>>> 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).
>>>
>>> Detailed description of why AWT behaves that way is quite lengthy &
>>> tangled. It can be found in the CR.
>>> Below I'll shortly comment the changes made. (The fix additionally
>>> contains changes not directly related to the 3 problems mentioned 
>>> above,
>>> but those changes were introduced based on thorough testing with the
>>> focus regression test base and analysing the failures).
>>>
>>> 1. Component.requestFocusHelper(..), Component.dispatchEventImpl(..),
>>> Container, Dialog, EventQueue
>>>
>>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Component.java.sdiff.html 
>>>
>>>
>>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Container.java.sdiff.html 
>>>
>>>
>>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Dialog.java.sdiff.html 
>>>
>>>
>>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/EventQueue.java.sdiff.html 
>>>
>>>
>>>
>>> A focus request, in order to set a type-ahead marker's time, uses the
>>> time stamp of the last dispatched _key_ event.
>>> A time stamp of a key event, which is put into the type-ahead queue,
>>> is not registered until the event is retrieved from the queue for
>>> normal dispatching.
>>> This establishes strong dependence b/w type-ahead markers and the
>>> order in which key events are actually dispatched.
>>>
>>> 2. Component.requestFocusHelper(..)
>>>
>>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Component.java.sdiff.html 
>>>
>>>
>>>
>>> As the comments say, a focus request following a mouse event is forced
>>> to be "in-window" focus requests. This is to make sure it won't
>>> re-activate the window
>>> in case the window is inactive by the time the request takes its turn
>>> for processing. This type of deferred side effect of the mouse event
>>> may not be correctly
>>> processed under "tough" conditions and should be dropped.
>>>
>>> 3. LWComponentPeer, LWWindowPeer
>>>
>>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWComponentPeer.java.sdiff.html 
>>>
>>>
>>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html 
>>>
>>>
>>>
>>> A simple (not Frame/Dialog) window or an active but not focused
>>> Frame/Dialog should request window focus by mouse click right on
>>> dispatching of the mouse event
>>> on the platform side, not after the event made the "platform -> java
>>> -> platform" cycle.
>>>
>>> 4. LWWindowPeer.dispatchKeyEvent(..)
>>>
>>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html 
>>>
>>>
>>>
>>> This is actually a fix for 7157015 (which I'll close later). The bug
>>> affects behavior and troubles testing of the whole fix, so I'm
>>> including this code as dependent.
>>>
>>> 5. XBaseWindow, XComponentPeer
>>>
>>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/solaris/classes/sun/awt/X11/XBaseWindow.java.sdiff.html 
>>>
>>>
>>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/solaris/classes/sun/awt/X11/XComponentPeer.java.sdiff.html 
>>>
>>>
>>>
>>> Similarly to (3), but for X11 implementation. Additionally,
>>> "actualFocusedWindow" reference, which is the most recent focused
>>> owned simple window, is reset because
>>> a click in an owned window should deliver focus to that window, not to
>>> the most recently focused one.
>>>
>>> 6. DefaultKeyboardFocusManager.repostIfFollowsKeyEvents(..)
>>>
>>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/DefaultKeyboardFocusManager.java.sdiff.html 
>>>
>>>
>>>
>>> (The change originally suggested by Oleg Pekhovskiy) Toplevel window
>>> focus events (WINDOW_GAINED_FOCUS/WINDOW_LOST_FOCUS) should not be
>>> processed
>>> until the type-ahead queue, populated before the event of switching
>>> toplevel windows actually happened, is empty. The only we can do here
>>> is to repost the toplevel focus
>>> events to the end of the EDT queue.
>>>
>>> 7. KeyboardFocusManagerPeerImpl
>>>
>>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java.sdiff.html 
>>>
>>>
>>>
>>> The calls:
>>>
>>> SunToolkit.postPriorityEvent(fl);
>>>
>>> were originally wrong. This is an artefact of an old fix (5028014)
>>> that has been rolled out, but went into jdk7 (with 6806217) by a 
>>> mistake.
>>> The focus events should not be sent in prioritized order here.
>>>
>>> 8. TimedWindowEvent
>>>
>>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/TimedWindowEvent.java.html 
>>>
>>>
>>>
>>> A WindowEvent with a time stamp.
>>>
>>> 9. SunToolkit
>>>
>>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/SunToolkit.java.sdiff.html 
>>>
>>>
>>>
>>> WINDOW_LOST_FOCUS event's time stamp is registered.
>>>
>>> 10. WindowsRootPaneUI
>>>
>>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java.sdiff.html 
>>>
>>>
>>>
>>> Skip menu activating events which weren't processed in time (while the
>>> containing toplevel window is active).
>>>
>>> 11. awt_Window.cpp
>>>
>>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/windows/native/sun/windows/awt_Window.cpp.sdiff.html 
>>>
>>>
>>>
>>> Window focus events are supplied with a time stamp.
>>>
>>> - - -
>>> Thanks,
>>> Anton.
>>>
>>