United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 4504821 Focus is not regained sometimes when alt-tabbing between applications
4504821 : Focus is not regained sometimes when alt-tabbing between applications

Details
Type:
Bug
Submit Date:
2001-09-19
Status:
Closed
Updated Date:
2002-06-17
Project Name:
JDK
Resolved Date:
2002-03-14
Component:
client-libs
OS:
solaris_7
Sub-Component:
java.awt
CPU:
sparc
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.4.0
Fixed Versions:
1.4.1

Related Reports
Relates:
Relates:

Sub Tasks

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


                                     
2004-08-24
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
                                     
2002-02-13



Hardware and Software, Engineered to Work Together