JDK-4940522 : Swing objects on the application do not recognize any mouse events
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.2_01
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2003-10-20
  • Updated: 2004-03-30
  • Resolved: 2004-02-04
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
1.4.2_05 05Fixed
Description
The ISV has run into a problem that we have been unable to resolve and 
believe it may be in the JRE itself.  We have run test cases against 
JRE 1.3.1.x and the problem does not occur, but when we run
against JRE 1.4.x, it happens every time.

The application test environment consists of:
- The 3D viewer (green background w/ trihedron in it), a native widge.
- A tree view, which reflect the contents of the 3D viewer, a native widget.
- Swing based toolbars and file load panel.  
- AWT buttons and text fields.

Here is the scenario.

In General:
We bring up our applications which contain a mixture of native windows,
Swing toolbars, and AWT objects.  We are able to bring up a right click
context menu from one of the native windows (the tree view) and make a
selection which brings up one of the native dialogs.  When we close out the
dialog, all swing objects on the application are essentially disabled, i.e.
they do not recognize any mouse events.


Specifically:
1.  We load a file into the 3D viewer.
2.  We then are able to add markups to the viewer using the Markup toolbar.
    Adding these markups causes an entry to be added to the tree view to group
    the markups, called "Markup Layer" with a sub entry of "Layer1".
3.  We then go into the tree view and right click on the markup layer
    (Layer1) itself to bring up one of the native context menus.  One of the
    entries is "Delete".  We select delete, which brings up one of the native
    dialogs, which prompts whether or not you want to save out this layer.
    After electing to save or not, the dialog is closed.  At this point, none of
    the swing components on the application will accept any kind of mouse event
    (toolbars and our file open panel).  They are completely unusable.  At this
    point the AWT components are still usable.  The only way to resolve the
    problem with the swing components is to right click in our tree view or
    viewer to bring up the context menu again.  

We have investigated both Native and Java solutions for the problem and have
not been able to determine what is actually happening to the swing
components.  

Platforms:

The problem occurs on Solaris 8, but it does not occur when running under Windows.
###@###.### 2003-10-20
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_05 generic tiger-beta2 FIXED IN: 1.4.2_05 tiger-beta2 INTEGRATED IN: 1.4.2_05 tiger-b37 tiger-beta2
24-08-2004
EVALUATION This could only happen if Swing is not getting MouseEvents. Reassigning to AWT for more investigation. ###@###.### 2003-10-20 Name: agR10216 Date: 12/03/2003 The bug is reproducible with JDK 1.4.2 build 25, but I couldn't reproducible it with the JDK 1.5.0 build 29. The sources of the problem application, PLM Vis 5.0, aren't available. As of JDK 1.4.2, ###@###.### reported that "I have traced this down to awt_MToolkit.c:1667 (attached) It appears that the second condition is not being met (xev.xfocus.mode == NotifyUngrab) and therefore the keyboardGrabbed variable is still true. This poses a problem when trying to post the event in question on line 737 where shouldDispatchToWidget() returns false instead of proceeding to line 829 and posting the event." In fact, FocusOut with mode=NotifyUngrab doesn't occur on the popup and keyboardGrabbed remains true. It's unknown why such is the case. since the sources aren't available and there is a lot of native code. ###@###.### 2003-12-03 ====================================================================== Name: agR10216 Date: 12/10/2003 The problem application performs unsynchronized calls to Xlib/Xt/Motif. AWT internally uses the marco AWT_LOCK and the methods of the class sun.awt.motif.AWTLockAccess to protect Xlib/Xt/Motif from simultaneous access by multiple threads, but the application, which there is a lot of native code in, does not. This explains my inability to reproduce the bug with the latest tiger builds (some timings changes as compared to mantis). Though there exists a test case, a slightly modified variant of the test case mentioned in the description. It's attached. I reproduced similar erroneous behavior with it using the tiger build 30. The submitter was recommended to consider using the lock (for example, via the class sun.awt.motif.AWTLockAccess) when accessing Xlib/Xt/Motif. Despite everything, the fix eliminates the particular problem mentioned in the description. ###@###.### 2003-12-10 ====================================================================== Since this is an escalation, I will commit it to Tiger. Note: SQE/A also considers this a must-fix for tiger. ###@###.### 2003-12-11
11-12-2003
SUGGESTED FIX Name: agR10216 Date: 12/03/2003 Pass by the code that sets/unsets the flag keyboardGrabbed if a RowColumn widget has no an AWT peer. The logic concerning keyboardGrabbed is aimed at AWT popups (see the evaluation of 4394847 for its description), so it can be safely bypassed for such widgets. This fix eliminates the submitter's problem and it shouldn't break any AWT functionality. *** /net/titan/export/gas/mantis/webrev/src/solaris/native/sun/awt/awt_MToolkit.c- Wed Dec 3 11:55:45 2003 --- awt_MToolkit.c Wed Dec 3 11:39:28 2003 *************** *** 1584,1589 **** --- 1584,1591 ---- return; } + peer = findPeer(&widget); + /* In general, we need to to block out focus events that are caused by keybaord grabs initiated by dragging the title bar or the scrollbar. But we *************** *** 1591,1597 **** choice boxes or menus. So we keep track of when the keyboard is grabbed by a popup. */ ! if (XtIsSubclass(widget, xmRowColumnWidgetClass)) { if (xev.type == FocusIn && xev.xfocus.mode == NotifyGrab) { extern Boolean poppingDown; --- 1593,1599 ---- choice boxes or menus. So we keep track of when the keyboard is grabbed by a popup. */ ! if (XtIsSubclass(widget, xmRowColumnWidgetClass) && peer != NULL) { if (xev.type == FocusIn && xev.xfocus.mode == NotifyGrab) { extern Boolean poppingDown; *************** *** 1624,1630 **** } } - peer = findPeer(&widget); if (peer == NULL) { #ifdef DEBUG_FOCUS printf("null peer -- shouldn't see in java handler\n"); --- 1626,1631 ---- ###@###.### 2003-12-03 ====================================================================== Name: agR10216 Date: 12/03/2003 More clear fix is: *** /net/titan/export/gas/mantis/webrev/src/solaris/native/sun/awt/awt_MToolkit.c- Wed Dec 3 13:55:01 2003 --- awt_MToolkit.c Wed Dec 3 13:54:06 2003 *************** *** 1591,1597 **** choice boxes or menus. So we keep track of when the keyboard is grabbed by a popup. */ ! if (XtIsSubclass(widget, xmRowColumnWidgetClass)) { if (xev.type == FocusIn && xev.xfocus.mode == NotifyGrab) { extern Boolean poppingDown; --- 1591,1597 ---- choice boxes or menus. So we keep track of when the keyboard is grabbed by a popup. */ ! if (XtIsSubclass(widget, xmRowColumnWidgetClass) && awt_isAwtWidget(widget)) { if (xev.type == FocusIn && xev.xfocus.mode == NotifyGrab) { extern Boolean poppingDown; ###@###.### 2003-12-03 ====================================================================== Name: agR10216 Date: 12/10/2003 The idea of the above fixes is right, but nor widgets corresponding to ordinary (not popup) AWT menus, nor any widget in their hierarchies have associated peers. The improved fix is to maintain a list of RowColumn widgets corresponding to AWT menus and bypass the code that operates with the flag keyboardGrabbed for widgets which are not in the list. ###@###.### 2003-12-10 ======================================================================
10-12-2003