JDK-6239944 : PIT: Right clicking on the scrollbar of the choice's dropdown disposes the drop-down, on XToolkit
  • 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-13
  • 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
Relates :  
JDK-4919214 - XAWT Choice does not post on popup after a slight motion before button release.
Description
I am showing a frame with a choice and a button. Click on the choice. A drop-down will be shown. Now click the right/middle button of the mouse on the scrollbar (either on the thumb or on the track). The drop-down disappears. This is reproducible only on XToolkit only on the following PIT build:

java version "awt.pit-awt-blade-2005-03-10-Thu-int.mustang"
Java(TM) 2 Runtime Environment, Standard Edition (build awt.pit-awt-blade-2005-03-10-Thu-int.mustang)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b26, mixed mode)

This is not reproducible on Mustang-b26. This is not reproducible on Motif and Win32. On Win32 and Motif, nothing happens when right clicking the mouse on the scrollbar. Hence this is a PIT failure. Related bug fix: 5003166

I have attached a sample test. Execute the sample test. You would see a frame with a button and a choice. Click on the choice. A drop-down will appear. Right click on the scrollbar of the drop-down. If the drop-down gets disposed, the bug is reproduced.
###@###.### 2005-03-13 17:38:12 GMT
###@###.### 2005-03-13 17:40:46 GMT
Comments
EVALUATION XChoicePeer.java has the following chunk: -------------------------------------- public void mouseReleased(MouseEvent e) { [...skip...] if ( !firstPress || unfurledChoice.isMouseEventInside( e ) ) { ungrabInput(); unfurledChoice.setVisible(false); unfurled = false; } [...skip...] -------------------------------------- This if-statement doesn't cover all cases when Choice must(or mustn't) close its pop-down menu. In this method we could operate with three parameters describing the state of choice: I) !firstPress (true is only when we press on non-opened choice) II) isMouseInListArea III) isMouseInside State matrix would look like this I II III action-XAWT action-Motif f f f no action no action (press on closed choice first time) t f f furl choice furl choice (pressing outside of choice and pop-down menu) t t t furl choice furl choice (selecting an item inside pop-down menu) t f t no action no action(but Middle Button scrolls SB like LEFTBUTTON) (pressing on scrollbar) f t t furl choice furl choice (user presses a mouse on Choice and drags it to select item in pop-down menu.) ###@###.### 2005-03-15 12:14:56 GMT When I pressing a mouse on closed Choice and then moving it slightly and then releasing a mouse I'm getting an closed Choice again. There is no contradictions with Motif but in 4919214 we've fixed this behaviour and became different with Motif. ###@###.### 2005-03-17 15:13:07 GMT
15-03-2005
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:07:29 GMT
15-03-2005