United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4940522 : Swing objects on the application do not recognize any mouse events

Details
Type:
Bug
Submit Date:
2003-10-20
Status:
Resolved
Updated Date:
2004-03-30
Project Name:
JDK
Resolved Date:
2004-02-04
Component:
client-libs
OS:
solaris_8
Sub-Component:
java.awt
CPU:
sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.2_01
Fixed Versions:
1.4.2_05 (05)

Related Reports
Backport:

Sub Tasks

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
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


======================================================================
                                     
2003-12-10
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
                                     
2003-12-11
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


                                     
2004-08-24



Hardware and Software, Engineered to Work Together