When you launch swing application and maximize it on Linux/JDS 3, the mouse cursor starts to change on wrong positions. The incorrect behaviour can is visible on SwingSet2 Demo in JDK. Steps to reproduce:

1. Launch the demo and choose JSplitPane (the one with astronaut). 
2. Maximize the window. 
3. Try to hover over the splitting line between the two images. The cursor doesn't change from arrow to the sliding cursor.

This bug seems to influence all swing applications. I report it due to problematic behaviour in  xxxxx , there are many mouse cursor changes which stop to work correctly when the window is maximized.
  xxxxx@xxxxx   2005-03-18 15:52:47 GMT

N/A

Cursor change is the result of Enter|LeaveNotify event. We set  XAwtState.setComponentMouseEntered() before changing cursor (XWindow.handleXCrossingEvent()). But seems there is no any EnterNotify events (as well as LeaveNotify) while maximizing window even mouse pointer is actually still inside toplevel.
Similar effect seen if we restore down ("normalize") that window.
I noticed that if I restore window and move mouse back into inner space of that window there is no EnterNotify event again. (But it will happen if you move mouse slowly into that window.) Believe the last one is a timing issue and shouldn't be considered like a bug.

To fix decribed problem we would make a detection of changing state of the window and initialize WeakRef on component under mouse. I tried to implement it in XFramePeer and it does work for SwingSet.
To be honest, it's unsufficient just to set that component to "this" in the cases of Maximization/Restoring. We should invent how to find that correct component.
Posted Date : 2005-12-08 14:56:27.0

After previous evaluation one place need to be clarified much: sun.awt.GlobalCursorManager uses  findHeavyweightUnderCursor() that actually returns cached XAwtState.componentMouseEnteredRef component. If some of EnterNotify event has missed then we probably get wrong componentUnder mouse variable.
There is another approach in MToolkit : we handle reference to current component under mouse on native level.
Posted Date : 2005-12-12 13:26:34.0

This bug happens often (on awt-linux-01, linux machines) because (as
described in my previous email) we skip crossingEvent and doesn't
initialize XAwtState's componentEntered variable. That variable is then
used in GlobalCursorManager to change cursor shape.
Initially I though it's WM error and it just misses one
Enter/LeaveNotify event but further testing uncovered a bug in awt :
XWindow.java : handleXCrossingEvent() skip events if they are not in
NotifyNormal mode.
I found that only some actions may lead to skipping that event.
(There are two instances will be considered in following: XContentWindow
and XFramePeer.)
In particular:
1) double clicking on titlebar of the window (it if leads to maximization)
  In this case we obtain
1) missed xEvent == XCrossingEvent = type = EnterNotify,
  xxxxx@xxxxx  (2c00007), mode = 2, detail = 1
2) missed xEvent == XCrossingEvent = type = EnterNotify,
  xxxxx@xxxxx  (2c0000e), mode = 2, detail = 0
Mode 2 means NotifyUngrab (it happens on second mouse release)
Detail 0 means NotifyAncestor
Detail 1 - NotifyVirtual
How does it work. When there are three windows: A(this is a root
window), B(XFramePeer), C(XContentWindow) and A is a parent of B and B
is a parent of C and crossing happens from A to C then B will receive
NotifyVirtual and C - NotifyAncestor.
You would imagine that similar things happen on crossing in other direction.

2) On pressing Alt-Tab:
Now lets consider pressing ALT+TAB (although there are no complains on
it in CR)
Java window initially activated and pointer over it and over other
window so when you release kbd pointer will come to different window:
(events will arrive on PRESS - this is significant)
1) missed xEvent == XCrossingEvent = type = LeaveNotify,
  xxxxx@xxxxx  (2c0000e), mode = 1, detail = 0
2) missed xEvent == XCrossingEvent = type = LeaveNotify,
  xxxxx@xxxxx  (2c00007), mode = 1, detail = 1
Similar situation - crossing happens affecting same windows like before:
Mode 1 == NotifyGrab
XContentWindow recieves NotifyAncestor and XFramePeer - NotifyVirtual
as a middle-point in this chain.

3) On pressin ALT+TAB
Other (read "native") window initially activated and pointer over it and
over Java window:
(events arrives on RELEASE - significant)
1) missed xEvent == XCrossingEvent = type = EnterNotify,
  xxxxx@xxxxx  (2c00007), mode = 2, detail = 1
2) missed xEvent == XCrossingEvent = type = EnterNotify,
  xxxxx@xxxxx  (2c0000e), mode = 2, detail = 0
You would notice exactly the same situation as in case 1).

We should correctly handle these events. I'm not sure about reasons of
filtering them for now and I'd filter them more precisely respecting
cases described above.
Posted Date : 2006-01-12 11:52:23.0

Seems there is no reasons to filter these XCrossing events based on their mode. So we should just handle all events. Suggested fix section contain two variants of the fix and the last one (simple one) should go into workspace.
Posted Date : 2006-02-06 09:58:59.0

We can't let Linux out of the picture. Don't forget that we use NetBeans on that platform too. We cannot distribute applications for use in Linux with this nasty, and I mean really nasty, bug.

Do not forget that we use jdk 5 for production, so this bug must be fixed in jdk 5 as soon as possible.

This must be fixed. Linux is critical for Java's success on the desktop.

This is a nasty bug affecting all swing apps on the Linux platform.

Why is Sun waiting *six additional months* for Mustang JDK6 to release this bugfix?

By then this bug will have been unresolved in the JDK production release for 18 months.

I'm having what sound like the same problem with NetBeans IDE 5.5.1.
If I maximize NetBeans and try to click on the menu or right click for the context menu, the pointer seems to be off by an inch, and selects the menu option that is an inch away to the left of what I've selected. Returning Netbeans to its' initial size (when it was first loaded) fixes the problem.

java -version
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode)

uname -a 
Linux eth0.lan 2.6.23.1-49.fc8 #1 SMP Thu Nov 8 21:41:26 EST 2007 i686 i686 i386 GNU/Linux

I use Blackbox 0.70.1 as the window manager

Thanks!