JDK-6458497 : Reopen #4841881: Alt tab with Windows L&F moves focus to the application menubar
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-08-09
  • Updated: 2012-08-16
  • Resolved: 2011-03-07
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.
JDK 6 JDK 7
6-poolUnresolved 7 b03Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0-rc"
Java(TM) SE Runtime Environment (build 1.6.0-rc-b94)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b94, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
When switching from a Java application to another application using Alt-TAB, focus shifts to the JMenuBar.  This means that when the user returns to the Java application, the menu bar has the focus, even if the user never intended to use the menu bar.

The problem only seems to occur when the time gap between hitting Alt and then TAB is short.  Anything under about 0.5s on my system shifts focus to the menu bar and leaves the focus there.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Compile and run the sample program, which has a JFrame and JMenuBar
2) Quickly press Alt-TAB to switch to another application; make sure that the time gap between pressing Alt and TAB is small

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The menu bar on the Java application should not be highlighted.
ACTUAL -
The menu bar on the Java application is highlighted.  After switching back to the application and then repeating the steps, the focus shift is undone, and now the menu bar is no longer highlighted.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.*;
import javax.swing.*;

public class AltTab {
  public static void main(String[] args) {
    try {
        UIManager.setLookAndFeel(UIManager
             .getSystemLookAndFeelClassName());
    } catch(Exception e) {
    }
    JFrame frame = new JFrame("Alt-Tab Frame");
    JMenuBar menuBar = new JMenuBar();
    frame.setJMenuBar(menuBar);
    JMenu fileMenu = new JMenu("File");
    char fileMenuMnemonic = 'F';
    fileMenu.setMnemonic(fileMenuMnemonic);
    menuBar.add(fileMenu);
    frame.setSize(100,100);
    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    frame.setVisible(true);
  }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
A workaround posted in the comments to bug #4841881 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4841881) works for the test case, but as the submitter mentioned, has potentially undesirable side effects.  The workaround doesn't work for a larger application I have created.  The problem existed in Java v.1.4.x, disappeared in v.1.5, and has reappeared in snapshots of v.1.6.

Comments
EVALUATION Actually, I believe that the previous evaluation is slightly wrong. We are having a race condition here. In normal circumstances, the following sequence of events happens: - User releases ALT - AWT receives a WM_KEYUP message and puts a corresponding KeyEvent into the EventQueue - WindowsRootPaneUI receives that KeyEvent and notifies BasicPopupMenUI that ALT has been released - BasicPopupMenu does grab() on the menu - The menu gets focused/highlighted - User releases TAB - AWT receives a WM_ACTIVATE messages, which is actually WA_INACTIVE - Native WA_INACTIVE handler does ungrab() on the menu - The menu loses focus/highlighting - By now, the user has switched to a different application However, since we do grab() in Java code as a result of the KeyEvent processing and ungrab() in native, it is possible that by the time the WM_ACTIVATE arrives the KeyEvent hasn���t been processed yet and still sits in the EventQueue. This leads to a situation where we ungrab() first (which does nothing because we haven���t grabbed anything yet), and then grab() later. When this happens (WM_ACTIVATE wins the race against KeyEvent), we get this bug.
16-08-2012

SUGGESTED FIX this fix has caused serious focus problem for applets. for corrected fix see 6506966.
17-01-2007

SUGGESTED FIX +++ awt_Component.cpp 2006-09-18 12:11:42.000000000 +0400 @@ -2195,10 +2195,16 @@ if (sm_focusOwner == hwnd) { return TRUE; } + HWND fgWindow = ::GetForegroundWindow(); + if (AwtComponent::GetComponent(fgWindow) == NULL) { + // fix for 6458497. we shouldn't request focus if it is out of our application. + return FALSE; + } + AwtFrame *owner = GetContainer()->GetOwningFrameOrDialog(); if (owner == NULL) { ::SetFocus(hwnd); if (::GetFocus() != hwnd) {
18-09-2006

EVALUATION 6469096 filed fo X part of the problem.
11-09-2006

EVALUATION the fix for windows works well (at least testing shows no regressions. But on X, we can not return window which is natively focused at the moment, since it breaks focus transfer for window (at least if we click on window which owner is not active at this moment. Our code first sets focus on frame (its proxy) then sends WINDOW_GAINED_FOCUS to window, but request focus on component in this window fails because we return frame as focused window (at this place our code wants window :( Perhaps it is worth to file separate bug for X, since the problem there is not so annoying.
07-09-2006

EVALUATION actually, on Windows, if we request focus when native focus is out of our application, the system sends us both WM_ACTIVATE and WM_SETFOCUS as we have focus but does change nothing from user's point of view. So, it looks reasonable to not request focus in such situation at all. Also I've found that we have similar (in term of focus) problem on X. There the cause of the problem is incorrect behavior of XKeyboardFocusManager.getCurrentFocusedWindow() and getCurrentFocusOwner() our code assumes that these methods return real native focused window/focus owner, but they return java focused window/focus owner.
04-09-2006

EVALUATION it looks like the problem is as follows: system deactivates the frame; Swing receives Alt and request focus on menu bar we do receive MW_ACTIVATE amd WM_SETFOCUS (but real active window is different) Swing starts grab we activate the grab since we believe that we are active. And we do not send unrgab event until someone again activate and de-activate us.
14-08-2006

EVALUATION reassigned to AWT
10-08-2006