JDK-4840883 : hourglass cursor & modal dialog
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.1,1.4.2
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2003-04-01
  • Updated: 2003-10-23
  • Resolved: 2003-08-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 Availabitlity Release.

To download the current JDK release, click here.
1.4.2_02 02Fixed
We have a JFrame displayed with a button that displays a modal dialog. Before displaying the dialog, we put a glasspane with an hour glass to simulate locking the GUI (our real app does some intensive server logic). When I hit OK on the dialog, another hour glass on the dialog is displayed to simulate more server logic and the dialog disappears....
The issue is after the dialog disappears the following scenarios happen:

    1. If after hitting the OK on the dialog AND the cursor
    remains OVER the dialog, then the cursor correctly
    changes back to a DEFAULT (arrow) cursor for the
    frame. This is correct and consistent on both
    Windows and Solaris.

    2. If after hitting the OK on the dialog AND the cursor
    remains OUTSIDE the dialog/OVER the frame, then
        --> On Windows: cursor correctly displays the default cursor
        --> On Solaris: cursor incorrectly displays the hourglass.

The testcase is attached

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_02 tiger tiger-beta FIXED IN: 1.4.2_02 tiger tiger-beta INTEGRATED IN: 1.4.2_02 tiger-b26 tiger-beta VERIFIED IN: 1.4.2_02

PUBLIC COMMENTS hourglass cursor & modal dialog

WORK AROUND There is a simple workaround to this. When you hit this bug, just move the mouse pointer out of the parent window where you noticed the problem. And re-enter mouse pointer in to the parent window. (By doing this you are cuasing a Mouse enter notify event, in which the problem gets corrected) ###@###.### 2003-05-01

EVALUATION Name: osR10079 Date: 04/02/2003 The problem is reproducible with all versions from 1.2.2. Thus this is not a hopper or mantis regression. ###@###.### ====================================================================== Name: osR10079 Date: 04/02/2003 I've found that this test uses custom SwingWorker (not from javax.swing) and user resets cursor back to normal in SwingWorker.finished() method. But this method isn't called (line in this custom SwingWoker which should call finished() is commented). But event when i decomment this line, finished is called only AFTER dialog will be hided, because user shows modal dialog in SwingWorker.construct(). Thus behavior observed on Solaris is correct. On Windows we have different behavior because of our modality implementation: we disable all toplevels, but Windows doesn't change cursor for disabled component. ###@###.### 2003-04-02 ====================================================================== Name: osR10079 Date: 04/13/2003 With corrected SwingWorker the problem is reproducible. We should investigate it. ###@###.### 2003-04-14 ======================================================================