JDK-4778281 : Alt-Tab while resizing JInternalFrame results in wrong cursor
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.1,5.0u4
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8,windows_nt
  • CPU: generic,x86
  • Submitted: 2002-11-13
  • Updated: 2006-06-14
  • Resolved: 2006-06-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 JDK 6
5.0u8 b02Fixed 6Fixed
Description
Name: jk109818			Date: 11/13/2002


FULL PRODUCT VERSION :
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)


FULL OPERATING SYSTEM VERSION :
Windows NT 4.00.1381 SP 6.0

A DESCRIPTION OF THE PROBLEM :
When I'm resizing a JInternalFrame a predefinid cursor is
showed, like Cursor.S_RESIZE_CURSOR, Cursor.N_RESIZE_CURSOR
or Cursor.SE_RESIZE_CURSOR etc.

When I change to another window in the system DURING the
resizing and I back to the Java application the cursor dont
change to default cursor type unless that I do another
resizing and complete it.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Start a Java application like SwingSet2 in the demo java
directory that have JInternalFrame windows.

2. Begin to resize a JInternalFrame window and in the same
time change to another window pressing ALT + TAB

3. Return to Java application. The java cursor is not
default cursor.

4. If you want the default cursosr resize another
JInternalFrame and COMPLETE the operation so the default
cursor will be showed.

EXPECTED VERSUS ACTUAL BEHAVIOR :
when I return to Java window the cursor must be the default
cursor.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
We can use the SwingSet2 java demo to example.
---------- END SOURCE ----------
(Review ID: 167009) 
======================================================================
Comments
EVALUATION Fix in BasicInternalFrameUI using WindowFocusListener. Call cancelResize() for a WINDOW_LOST_FOCUS event on the first Window ancestor of the JInternalFrame.
20-06-2006
EVALUATION We are still evaluating whether to fix it in AWT, but for this escalation we are just going to fix it in Swing.
22-05-2006
WORK AROUND Add focus listener to the button and call mouseReleased on the JInternalFrame's mouselistener button.addFocusListener(new FocusListener() { public void focusGained(FocusEvent e) { } public void focusLost(FocusEvent e) { MouseListener [] listeners = MyInternalFrame.this.getMouseListeners(); for (int i=0; i<listeners.length; i++) { listeners[i].mouseReleased(null); } } });
16-05-2006
EVALUATION Rather than fix this in numerous places in Swing, it seems it would be better for AWT, on a focusLost event, to send a mouseReleased event to the last component to which it sent a mousePressed event, and to which it has not yet sent a mouseReleased event. Then that component would do what it normally does to terminate a resize, scroll, etc..
16-05-2006
EVALUATION AWT should send a mouse release only to the last component which received a mouse press, but has not yet received a mouse release. Better to fix this in one place in AWT than try to fix it in multiple places in Swing. Swing depends on AWT for event notification.
15-05-2006
EVALUATION This is definitely a Swing bug. It is caused by the following: BasicInternalFrameUI uses a glassPane to catch the mouse events from the container during resize. It shows the glassPane when the resizing drag starts, and hides it back on mouseRelease. In certain circumstances (like the one in this bug) mouseRelease is not received, this causes the problem. Supposedly the glassPane should also be hidden on window focus loss, maybe also in certain other circumstances.
05-05-2006
EVALUATION Needs more investigation. I believe there is already another bug open regarding this bug that is targeted for the next release. I will close this as a duplicate once I find that bug id. ###@###.### 2002-11-14 Wasn't able to to reproduce this under linux using 1.4.1b21. Need to try under Win2000. ###@###.### 2003-08-26 Reproducible on 1.6.0-ea-b44. This looks like an AWT bug. Reassigning to AWT for further evaluation.
26-08-2003