JDK-4504821 : Focus is not regained sometimes when alt-tabbing between applications
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_7
  • CPU: sparc
  • Submitted: 2001-09-19
  • Updated: 2002-06-17
  • Resolved: 2002-03-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.1 hopperFixed
Related Reports
Relates :  
JDK-4524015 - WINDOW_ACTIVATED and WINDOW_ DEACTIVATED events are not always fired
Relates :  
JDK-4503980 - Focus lost/gain events get lost when gaining focus on external CDE component
Description
This is an offshoot of bugid 4503980.  This description is taken from the 
Evaluation of that bug.  

Use the Split-Pane demo in Swingset2.  I assume this is all in 
point-to-focus mode.  

1.  Click in one of the textfields in the demo. 
2.  Click on an external window (another app) to change focus.  
3.  Alt-tab to give focus back to the Swingset 

The textfield will not have focus.  
However, you can give focus to the textfield by clicking in it.  


Below is the evaluation for Merlin by ###@###.###, tested with Merlin b78

In native code we listen only for one kind of Focus event - one with mode == NotifyNormal. When one uses special key sequences handled by WM which make windows focused/unfocused WM sends different kinds of Focus events (for example on my IceWM I receive FocusOut NotifyGrab, then NotifyWhileGrabbed when I switch out of application, then FocusIn NotifyWhileGrabbed, NotifyUngrab when I switch back). We skip all this events in awt_MToolit.c:processOneEvent.

If you have Java windows focused and click with mouse to another window on desktop then Java receives FocusOut NotifyNormal which we process and CLEAR focus. Therefor when you switch back using key sequence, and we doestn't receive any Focus events we listen to, we doesn't restore focus and frame looks active and not having focus. To restore focus you can just click on the component you want to make it focused. 

Workaround: ###@###.###
Don't mix mouse and keyboard application switch, if you switched out of Java by mouse return back also by mouse. If you switched out of Java by keyboard, you can switch back either by keyboard or mouse.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper FIXED IN: hopper INTEGRATED IN: hopper VERIFIED IN: hopper-beta
24-08-2004
EVALUATION Committing to hopper and tiger. ###@###.### 2001-11-05 Reassigning to Russia. ###@###.### 2001-11-06 Name: rpR10076 Date: 11/16/2001 commit to hopper and tiger ====================================================================== Name: dmR10075 Date: 02/13/2002 On Solaris, when user presses Alt-Tab key combination WM may switch focus to another window. When it performs the switch it usually sends the following sequence of events: - FocusOut NotifyGrab, FocusOut NofityWhileGrabbed to the currently active window - FocusIn NotifyWhileGrabbed, FocusIn NotifyUngrab to the new acive window In native code, in awt_MToolkit.c:processOneEvent and awt_TopLevel.c:shellEH we skip all such events and doens't dispatch them to Java. Therefor when user presses Alt-tab no event is generated to Java. To fix this we at first should add code which will process these events. However, it was found that some other user actions may generate this kind of event (not NotifyNormal) when user doesn't expect any events would be generated to Java. These cases are: selecting menu item in main menu, popping up/down of popup menu, selecting the item in choice's list, clicking on menu bar on the space where there is no items. All such a cases generate NotifyWhileGrabbed/NotifyGrab/NotifyUngrab event in different sequences so we should filter them and distinguish the source of such event - was they generated as the result of Alt-tab switching or not. Two approaches can used to implement this. 1. Try to detect the opposite window of every native focus transfer. When user switches by Alt-tab the opposite window is either another Frame/Window or none if it is the transfer outside of Java application. If he presses menu, popup menu, choice it is either GrabShell or MenuShell. So, by this we can guaranteely detect the case of user actions and distinguish them. However, the actual implementation looks very complicated and so it was decided to not use this if another approach will work as good as this one. 2. Mark the moment when the menu/popup menu/choice pops up/down and skip the following events according to this mark. We install the callbacks for popup/popdown events of the appropriate shells and set some flags in native code. When the events arrive we check the flags and decide whether or not to allow it to be processed. Implementation of this approach looks more simple and safe so it was decided to use it. ###@###.### 2002-02-13 ====================================================================== Verified using SwingSet2 demo with Hopper b14. ###@###.### 2002-06-17
13-02-2002