United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4478780 : Regression: Solaris: Unable to select items in choice's menu by keyboard

Details
Type:
Bug
Submit Date:
2001-07-11
Status:
Resolved
Updated Date:
2002-11-01
Project Name:
JDK
Resolved Date:
2002-11-01
Component:
client-libs
OS:
solaris_2.6
Sub-Component:
java.awt
CPU:
sparc
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.4.0
Fixed Versions:
1.4.2 (mantis)

Related Reports

Sub Tasks

Description
The bug is reproducible starting from b70. It looks like the regression from fix for 4397557. I confirmed that removing that fix restores normal behavior.

Steps to reproduce:
1. Run regression test test/java/awt/Focus/WindowTest
2. Click on button "Button" by mouse to make it focused.
3. Press Tab key several times so Choice will become focused.
4. Press Space, Choice's menu will appear.
5. Using arrow keys try to select item and press Space to accept the selection and to close the menu. - Starting from b70 you will not be able to do this. There is no other way to select or close the menu other then by mouse.


                                    

Comments
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

======================================================================
                                     
2002-10-14
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();

======================================================================
                                     
2004-08-24
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mantis

FIXED IN:
mantis

INTEGRATED IN:
mantis
mantis-b06


                                     
2004-08-24



Hardware and Software, Engineered to Work Together