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