JDK-6240046 : REG:Choice's Drop-down does not disappear when clicking somewhere, after popup menu is disposed-XTkt
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2005-03-14
  • Updated: 2011-01-19
  • Resolved: 2005-04-18
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.
JDK 6
6 b33Fixed
Related Reports
Relates :  
JDK-5003166 - REG:Mouse button not validated before bringing up the drop-down menu for choice
Description
I have a choice and I have added a popup menu to it. I am clicking on the choice and the drop-down menu appears. Right click inside the drop-down. A popup menu will be shown. Navigate through the sub-menus and click one of the menuitems. The popup menu will disappear. Now click on the frame somewhere or click on the button. Click on some native application. The drop-down menu of the choice will not disappear. It stays there until user goes and clicks the choice again. 

This is reproducible only on XToolkit since Tiger. Not reproducible on Motif and Win32. On Motif and Win32, right clicking inside the drop-down does not bring up the popup menu.

Run the attached test on XToolkit and click the Choice. Right click inside the drop-down and click on some menuitem in the popup menu. After that, click somewhere on the frame or click on the button. If the drop-down does not disappear, the bug is reproduced.
###@###.### 2005-03-14 10:26:33 GMT
Comments
SUGGESTED FIX src/solaris/classes/sun/awt/X11/XChoicePeer.java- 22 18:13:59 2005 *************** *** 297,302 **** --- 297,311 ---- } } + /* + * helper method for mouseReleased routine + */ + void hidePopdownMenu(){ + ungrabInput(); + unfurledChoice.setVisible(false); + unfurled = false; + } + public void mouseReleased(MouseEvent e) { if (unfurled) { if (mouseInSB) { *************** *** 308,318 **** // unfurled. // This release should ungrab/furl, and set the new item if // release was over the unfurled Choice. ! if ( !firstPress || unfurledChoice.isMouseEventInside( e ) ) { ! ungrabInput(); ! unfurledChoice.setVisible(false); ! unfurled = false; } if (!helper.isEmpty()) { // Only update the Choice if the mouse button is released --- 317,353 ---- // unfurled. // This release should ungrab/furl, and set the new item if // release was over the unfurled Choice. ! ! // Fix for 6239944 : Choice shouldn't close its ! // pop-down menu if user presses Mouse on Choice's Scrollbar ! // some additional cases like releasing mouse outside ! // of Choice are considered too ! boolean isMouseEventInside = unfurledChoice.isMouseEventInside( e ); ! boolean isMouseInListArea = unfurledChoice.isMouseInListArea( e ); ! // Choice must be closed if user releases mouse on ! // pop-down menu on the second click ! if ( !firstPress && isMouseInListArea) { ! hidePopdownMenu(); } + // Choice must be closed if user releases mouse + // outside of Choice's pop-down menu on the second click + if ( !firstPress && !isMouseEventInside) { + hidePopdownMenu(); + } + //if user drags Mouse on pop-down menu, Scrollbar or + // outside the Choice + if ( firstPress && dragging) { + hidePopdownMenu(); + } + /* this could happen when user has opened a Choice and + * released mouse button. Then he drags mouse on the + * Scrollbar and releases mouse again. + */ + if ( !firstPress && !isMouseInListArea && + isMouseEventInside && dragging) + { + hidePopdownMenu(); + } if (!helper.isEmpty()) { // Only update the Choice if the mouse button is released *************** *** 754,758 **** --- 789,833 ---- } super.dispose(); } + + /* + * fix for 6239938 : Choice drop-down does not disappear when it loses + * focus, on XToolkit + * We are able to handle all _Key_ events received by Choice when + * it is in opened state without sending it to EventQueue. + * If Choice is in closed state we should behave like before: send + * all events to EventQueue. + * To be compatible with Motif we should only handle VK_TAB in + * Choice. All other KeyEvents should be sent into Java. + */ + boolean prePostEvent(final AWTEvent e) { + if (e instanceof KeyEvent && ((KeyEvent)e).getKeyCode() == KeyEvent.VK_TAB && unfurled) + { + EventQueue.invokeLater(new Runnable() { + public void run() { + handleJavaKeyEvent((KeyEvent)e); + } + }); + // notify XWindow that this event had been already handled and no + // need to post it again + return true; + } + // Fix for 6240046 : REG:Choice's Drop-down does not disappear when clicking somewhere, after popup menu is disposed-XTkt + // if user presses Right Mouse Button on opened (unfurled) + // Choice then we mustn't open a popup menu. We could filter + // Mouse Events and handle them in XChoicePeer if Choice + // currently in opened state. + if (e instanceof MouseEvent && unfurled){ + EventQueue.invokeLater(new Runnable() { + public void run() { + handleJavaMouseEvent((MouseEvent)e); + } + }); + // notify XWindow that this event had been already handled and no + // need to post it again + return true; + } + return super.prePostEvent(e); + } } src/solaris/classes/sun/awt/X11/XWindow.java- 22 18:14:00 2005 *************** *** 311,317 **** return target.getBounds(); } ! void prePostEvent(AWTEvent e) { } static Method m_sendMessage; --- 311,322 ---- return target.getBounds(); } ! /** ! * Returns true if the event has been handled and should not be ! * posted to Java. ! */ ! boolean prePostEvent(AWTEvent e) { ! return false; } static Method m_sendMessage; *************** *** 350,359 **** } public void postEventToEventQueue(final AWTEvent event) { ! prePostEvent(event); ! postEvent(event); } ! // We need a version of setBackground that does not call repaint !! // and one that does not get overridden. The problem is that in postInit // we call setBackground and we dont have all the stuff initialized to --- 355,367 ---- } public void postEventToEventQueue(final AWTEvent event) { ! //fix for 6239938 : Choice drop-down does not disappear when it loses focus, on XToolkit ! if (!prePostEvent(event)) { ! //event hasn't been handled and must be posted to EventQueue ! postEvent(event); ! } } ! // We need a version of setBackground that does not call repaint !! // and one that does not get overridden. The problem is that in postInit // we call setBackground and we dont have all the stuff initialized to ###@###.### 2005-03-22 16:10:41 GMT
22-03-2005
EVALUATION This behaviour is different from Motif's. User mustn't see opened popup menu while Choice is opened too. To fix this we shouldn't transfer MouseEvent to unfurled choice and this will prevent popup menu from being opened. ###@###.### 2005-03-14 12:53:10 GMT Should filter MouseEvents in XChoicePeer.prePostEvent(). Depends on Choice's state (closed/unfurled) we could handle it by Choice or transfer it into Java EventQueue. On Motif when user presses RightMouseButton on opened(unfurled) Choice no popup menu appears. In this case Choice just closing. ###@###.### 2005-03-22 09:31:52 GMT
14-03-2005