JDK-4478780 : Regression: Solaris: Unable to select items in choice's menu by keyboard
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_2.6
  • CPU: sparc
  • Submitted: 2001-07-11
  • Updated: 2002-11-01
  • Resolved: 2002-11-01
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 mantisFixed
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
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b06
24-08-2004

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(); ======================================================================
24-08-2004

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