On Red Hat EL 4, after a JFrame is resized in a certain way, the mouse cursor
can get stuck so that it is locked to the arrow pointer shape.
OPERATING SYSTEM(S):
Red Hat EL 4
FULL JDK VERSION(S):
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode)
DESCRIPTION:
1. Compile and run "java SimpleSplitPane" (source code below)
2. Move the mouse over the split pane divider bar, notice that the mouse cursor
   changes to a double-ended arrow to show the user that the divider can move
   left and right.
3. Right mouse click on the lower right hand corner of the window to resize.
   Drag the corner to make the window bigger, don't release the mouse yet,
   change direction of drag to make the window smaller. Release the mouse on the
   inward sweep so the mouse pointer never goes outside the window.
4. Don't move the mouse pointer outside the window.
5. Now move the mouse pointer over the split pane divider bar. Notice that the
   mouse cursor no longer changes into the double-ended arrow. It is locked to
   the arrow pointer shape.
   
//===========================================================================
import javax.swing.*;
import java.awt.*;
class SimpleSplitPane extends JFrame {
    SimpleSplitPane() {
        super("SimpleSplitPane");
        setDefaultCloseOperation(EXIT_ON_CLOSE);
        /*
         * Centre the frame on the screen
         */
        int width = 400;
        int height = 400;
        Dimension sz = Toolkit.getDefaultToolkit().getScreenSize();
        this.setBounds((sz.width - width)/2,(sz.height - height)/2,width,height);
        setSize(width, height);
        add(new JSplitPane());
        show();
    }
    static public void main(String[] args) {
        new SimpleSplitPane();
    }
}
//===========================================================================
Please note that the problem is not limited to JSplitPane. You can recreate the
problem using any component inside the JFrame that normally makes the mouse
cursor change. For example, a JEditorPane HTML link that should make the mouse
change to the pointing hand, or the border of a JInternalFrame that should make
the mouse change to a resize arrow. You can see both of these examples by
running the relevant SwingSet2 demos and resizing the window as described above.
Diagnosis / Suggested fix:
This problem appears to be limited to XAWT on Red Hat.
X sends a NotifyLeave event when you start to resize
the window, and a NotifyEnter event when you finish
resizing and move back into the window. However on
RedHat the NotifyEnter event has its mode value set
to NotifyUngrab and the code ignores any NotifyEnter
or NotifyLeave event with a mode that is not NotifyNormal.
This prevents the necessary call to
XAwtState.setComponentMouseEntered( <component> ).
This in turn makes XGlobalCursorManager.findHeavyWeightUnderCursor()
return null. This means that GlobalCursorManager._updateCursor()
returns without doing anything. The _updateCursor()
method is called by updateCursorImmediately(), which
is the method responsible for keeping the mouse pointer
displaying the correct cursor.
The suggested fix is in sun.awt.X11.XWindow:
 $ diff -p XWindow.java XWindow.java.fix
*** XWindow.java 2004-12-07 01:50:44.000000000 +0000
--- XWindow.java.fix 2005-09-28 16:32:34.133716984 +0100
*************** public class XWindow extends XBaseWindow
*** 655,661 ****
          if (eventLog.isLoggable(Level.FINE)) eventLog.fine(xce.toString());
          // Skip event If it was caused by a grab
! if (xce.get_mode() != NotifyNormal) {
              return;
          }
--- 655,662 ----
          if (eventLog.isLoggable(Level.FINE)) eventLog.fine(xce.toString());
          // Skip event If it was caused by a grab
! if (xce.get_mode() != NotifyNormal &&
! xce.get_mode() != NotifyUngrab) {
              return;
          }