SUGGESTED FIX
Name: dmR10075 Date: 10/15/2002
------- awt_TopLevel.c -------
*** /tmp/sccs.lXa4Fw Tue Oct 15 14:43:02 2002
--- awt_TopLevel.c Tue Oct 15 14:27:26 2002
***************
*** 1235,1240 ****
--- 1235,1247 ----
}
}
}
+ } else {
+ // If there is no opposite shell but we have active popup - this popup
is actually
+ // the oppposite. This should mean that this focus out is due to popup -
and thus
+ // should be skipped. Fix for 4478780.
+ if (skipNextNotifyWhileGrabbed) {
+ break;
+ }
}
// If current window is not focusable and opposite window is not focusable -
do nothing
------- Component.java -------
*** /tmp/sccs.gLaqFw Tue Oct 15 14:43:01 2002
--- Component.java Tue Oct 15 14:39:20 2002
***************
*** 3473,3499 ****
}
}
- /**
- * Fix for 4495473.
- * This fix allows to correctly dispatch events when native
- * event proxying mechanism is active.
- * If it is active we should redispatch key events after
- * we detected its correct target.
- */
- if (e instanceof KeyEvent) {
- KeyEvent ke = (KeyEvent)e;
- if (KeyboardFocusManager.isProxyActive(ke)) {
- Container target = getNativeContainer();
- if (target != null) {
- ComponentPeer peer = target.getPeer();
- if (peer != null) {
- peer.handleEvent(e);
- }
- }
- return;
- }
- }
-
// MouseWheel may need to be retargeted here so that
// AWTEventListener sees the event go to the correct
// Component. If the MouseWheelEvent needs to go to an ancestor,
--- 3473,3478 ----
------- DefaultKeyboardFocusManager.java -------
*** /tmp/sccs.hHaWEw Tue Oct 15 14:43:01 2002
--- DefaultKeyboardFocusManager.java Tue Oct 15 14:40:42 2002
***************
*** 793,798 ****
--- 793,821 ----
// KeyEventDispatchers will use the correct time.
EventQueue.setCurrentEventAndMostRecentTime(ke);
+ /**
+ * Fix for 4495473.
+ * This fix allows to correctly dispatch events when native
+ * event proxying mechanism is active.
+ * If it is active we should redispatch key events after
+ * we detected its correct target.
+ */
+ if (KeyboardFocusManager.isProxyActive(ke)) {
+ Component source = (Component)ke.getSource();
+ Container target = source.getNativeContainer();
+ if (target != null) {
+ ComponentPeer peer = target.getPeer();
+ if (peer != null) {
+ peer.handleEvent(ke);
+ /**
+ * Fix for 4478780 - consume event after it was dispatched by peer.
+ */
+ ke.consume();
+ }
+ }
+ return true;
+ }
+
java.util.List dispatchers = getKeyEventDispatchers();
if (dispatchers != null) {
for (java.util.Iterator iter = dispatchers.iterator();
======================================================================
|
EVALUATION
Committing to merlin. Severe regression.
david.mendenhall@east 2001-07-11
Name: dsR10078 Date: 08/02/2001
Not reproducible on b69.
Reproducible on b73.
###@###.### 2001-08-02
======================================================================
Name: rpR10076 Date: 11/16/2001
commit to hopper and tiger
======================================================================
Name: dmR10075 Date: 03/04/2002
The bug is still reproducible with Hopper b02. However, it takes time to reproduce it,
also you need to mix keyboard and mouse item selection. After the problem has been
reproduced key events are still being reported in Java, but seems that they are not
being correcly dispatched to Motif. Also Choice doesn't have focus frame while it is
focused.
###@###.###
======================================================================
Name: dmR10075 Date: 03/11/2002
Two problems I see here with this particular test:
- focus owner is getting cleared every time we click on Window
(or its child) because of proxy activation-deactivation. This needs
to be investigated. However, this problem is more general and deep than
just 'choice focus problem', it affects other components as well.
- focus on widgets is requested when Window's shell is not active in terms
of how Motif treats active shells. Thus, focus requests are processed differently
in this case comparing to active shell. Again, it is because of proxy and it is
also very general problem.
In the case of Frame(test/java/awt/Focus/AltTabFocus for example) choice behaves well
in Hopper, I think it is because there is no Motif 1.2.
So, this bug requires more deep investigation, but we don't have a time for it
in Hopper, so I commit it to Mantis.
###@###.### 2002-03-11
======================================================================
Name: dmR10075 Date: 10/14/2002
Focus gets cleared because of FocusOut event coming due to raised popup shell -
choice's GrabShell. We should avoid generating Java events for this event. One
of the possible solutions is to use already existing skipNextNotifyWhileGrabbed
variable which is being set when grab shell arises.
Another problem discovered while investigating this bug: as from Mantis b02 the
problem with two keys on one press exists again(see 4495473). It is now because
all key events in Window come to peers twice - in
dispatchEventImpl(Component.java:3490) and
dispatchKeyEvent(DefaultKeyboardFocusManager:658). The error is in
Component.java - the code there doesn't take into account that it will be called
from inside DKFM dispatch event sequence and at the end of it normal
peer.handleEvent will be called. To prevent doble-dispatching we should consume
the event in Component.java as the code there assumes that no further processing
of the event occurs. Also, to simplify the code in dispatchEventImpl this code
should better be moved to join other parts of code dealing with key event
pre-dispatching - to preDispatchKeyEvent(DKFM:781).
One problem still exists - after I select some item from the choice's list using mouse
choice doesn't regain focus after closing of the menu.
###@###.### 2002-10-14
======================================================================
|
Java