JDK-6434227 : Popup menus when rendered on X Client can't be selected w/ mouse
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2006-06-06
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
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.
7 b07Fixed
Related Reports
Relates :  
Relates :  
Relates :  
java version "1.6.0-beta2"
Java(TM) SE Runtime Environment (build 1.6.0-beta2-b76)
Java HotSpot(TM) Client VM (build 1.6.0-beta2-b76, mixed mode, sharing)

X server: Solaris 10.  X Client: Windows 2000 running latest CygWin/X library

JDK needs to use XToolkit for rendering to reproduce this.
setenv AWT_TOOLKIT XToolkit

Given a simple swing app that has either a main menu with a dropdown, or a popup menu, run the app via X, rendered onto a client workstation using XToolkit renderer.

Try to select an item on the dropdown menu by clicking on the menu to get the pull down, then clicking on the item.  When you release the mouse after getting the drop down, the menu does not stick, it disappears, making it impossible to use the mouse to select the item with the second click.

1. Swing app with JMenu that has a drop down with at least one item (or a popup menu access via right mouse click - same problem).
2. setenv AWT_TOOLKIT XToolkit to force use of XToolkit (I heard this would be a mustang default on Solaris, but it does not seem to be in this case.)
3. Run app, rendered onto a second X workstation behaving as client. (I used latest Cygwin/X on Windows/2000 over DSL connection)  It does not matter whether lbx_proxy is used or not - I reproduced problem both ways.
4. Click the main menu (and release the mouse button) to get the drop down menu to appear.

Menu would stay visible allowing user to select the menu item they wanted.
Menu disappears making it impossible to select anything via the mouse.

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Just create a JFrame w/ menubar, one pulldown w/ one or two items on the pulldown.
---------- END SOURCE ----------

Press and hold the mouse to get the menu to appear.  Then while holding the mouse button down, use the arrow keys on the keyboard to select the item you want, then hit enter to select it.  The work around is incredibly annoying but it works.

Release Regression From : 5.0u6
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

EVALUATION This problem is resolved in JDK 6u1 with the fix for 6429775, so it is not reproducible with JDK 6u10.

SUGGESTED FIX see 6429775

EVALUATION should be fixed altogether with 6429775 (Xgl/Compiz/Java 1.5/Swing problem) in jdk7

SUGGESTED FIX Here is a simple fix which could be committed to update release for 6.0, though it is better to rewrite part of insets code (imho). ------- XDecoratedPeer.java ------- *** /tmp/sccs.SrLSq9 2006-08-31 20:00:16.000000000 +0400 --- XDecoratedPeer.java 2006-08-31 20:00:11.000000000 +0400 *************** *** 663,672 **** ComponentAccessor.getY((Component)target), ComponentAccessor.getWidth((Component)target), ComponentAccessor.getHeight((Component)target)); - WindowDimensions targetDimensions = new WindowDimensions(targetBounds, copy(currentInsets), false); Point newLocation = targetBounds.getLocation(); ! if (xe.get_send_event()) { // Location, Client size + insets newLocation = new Point(xe.get_x() - currentInsets.left, xe.get_y() - currentInsets.top); } else { --- 663,671 ---- ComponentAccessor.getY((Component)target), ComponentAccessor.getWidth((Component)target), ComponentAccessor.getHeight((Component)target)); Point newLocation = targetBounds.getLocation(); ! if (xe.get_send_event() || runningWM == XWM.NO_WM) { // Location, Client size + insets newLocation = new Point(xe.get_x() - currentInsets.left, xe.get_y() - currentInsets.top); } else { ------- XWM.java ------- *** /tmp/sccs.SGA0wb 2006-08-31 20:00:49.000000000 +0400 --- XWM.java 2006-08-31 19:59:06.000000000 +0400 *************** *** 1455,1460 **** --- 1455,1465 ---- window, lwinAttr.pData); status = XlibWrapper.XGetWindowAttributes(XToolkit.getDisplay(), parent, pattr.pData); + if (lwinAttr.get_root() == parent) { + insLog.finest("our parent is root so insets should be zero"); + correctWM = new Insets(0, 0, 0, 0); + break; + } /* * Check for double-reparenting WM. * *************** *** 1489,1499 **** parent = qt.get_parent(); XlibWrapper.XGetWindowAttributes(XToolkit.getDisplay(), parent, ! pattr.pData); } } finally { qt.dispose(); ! } } /* * XXX: To be absolutely correct, we'd need to take --- 1494,1504 ---- parent = qt.get_parent(); XlibWrapper.XGetWindowAttributes(XToolkit.getDisplay(), parent, ! pattr.pData); } } finally { qt.dispose(); ! } } /* * XXX: To be absolutely correct, we'd need to take

EVALUATION So, we detect Cygwin os NO_WM. Than we have two bugs in our code: 1. XWM.guessInsets() there is no check if our parent is root and so we incorrectly caclulate our insets. 2. XDecoratedPeer.handleConfigureNotifyEvent() we do update location of target only if we either receive this event from WM (send_event == true), or for some buggy WMs. It looks like we should also updated it for NO_WM case.

EVALUATION Well, we detect WM is NO_WM in this situation :(

EVALUATION it looks like the cause ofthe problem is that this WM repartns us to the root, but we consider our parent as just a parent and incorrectly calculate locations (which is always (0,0) since these are coordinates of root) and our insents (which should be (0,0,0,0), but we believe that insents are (0, 0, 1001, 1144) on my monitor)

EVALUATION It looks like the cause of the problem is that we incorrectly caclulates insets and location on screen in case of Cygwin native WM :( As a workaroung user may use MToolkit (set emv var AWT_Toolkit to MToolkit). Or use Cygwing's X in fullscreen mode. Here is a small test to check insets and location: import java.awt.Button; import java.awt.Frame; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; public class location_test { public static void main(String[] args) { final Frame frame = new Frame("location test"); Button button = new Button("get locationon screen"); button.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent ae) { System.out.println("insets = " +frame.getInsets()); System.out.println("location = " + frame.getLocationOnScreen()); } }); frame.add(button); frame.pack(); frame.setVisible(true); } }

EVALUATION Sounds similar to 6362692 and it should also be reproducible on linux KDE.

EVALUATION I've managed to reproduce it only once with JDK6.0b76 and haven't with JDK6.0b85. I tried Solaris9,10 with JDS and CDE. This might relate to 6390326. Please check this issue once again with JDK6.0b85 which contains patch for menus.

EVALUATION Recently we already dealt with similar request. I'm trying to find the CR number(s) and to reproduce it with JDK6.0b76 and current build to be sure.

EVALUATION Since I can't reproduce it on any available platforms I'm making it incomplete. 1) Please provide your testcase for this issue if possible. (BTW, could it be reproduced with SwingSet?) 2) if it happens on CDE/JDS or something else? 3) it's not clear if you tried JDK5.0 with XToolkit or MToolkit?

EVALUATION Actually, more like AWT :)

EVALUATION Looks like a Swing problem.