FULL PRODUCT VERSION :
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)

ADDITIONAL OS VERSION INFORMATION :
X server: Solaris 10.  X Client: Windows 2000 running latest CygWin/X library

EXTRA RELEVANT SYSTEM CONFIGURATION :
JDK needs to use XToolkit for rendering to reproduce this.
setenv AWT_TOOLKIT XToolkit

A DESCRIPTION OF THE PROBLEM :
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.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
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.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Menu would stay visible allowing user to select the menu item they wanted.
ACTUAL -
Menu disappears making it impossible to select anything via the mouse.

REPRODUCIBILITY :
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 ----------

CUSTOMER SUBMITTED WORKAROUND :
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.
Posted Date : 2006-06-06 00:11:18.0

N/A

Looks like a Swing problem.
Posted Date : 2006-06-06 07:45:08.0

Actually, more like AWT :)
Posted Date : 2006-06-06 15:47:28.0

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.
Posted Date : 2006-06-07 11:10:45.0

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.
Posted Date : 2006-06-07 11:39:26.0

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?
Posted Date : 2006-06-07 12:08:22.0

Sounds similar to 6362692 and it should also be reproducible on linux KDE.
Posted Date : 2006-07-03 10:08:30.0

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);
    }
}
Posted Date : 2006-08-01 11:23:30.0

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)
Posted Date : 2006-08-31 11:17:31.0

Well, we detect WM is NO_WM in this situation :(
Posted Date : 2006-08-31 15:05:20.0

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.
Posted Date : 2006-08-31 15:56:32.0

should be fixed altogether with 6429775 (Xgl/Compiz/Java 1.5/Swing problem) in jdk7
Posted Date : 2006-12-01 16:17:40.0

This problem is resolved in JDK 6u1 with the fix for 6429775, so it is not reproducible with JDK 6u10.
Posted Date : 2008-05-29 07:09:18.0

My standard test case is NetBeans, since I'm trying to run NetBeans from my Solaris box at work, with the UI rendered on my workstation at home, running over 1.5 Mb DSL

I will try again with Mustang B90, since that is what is current now.

I used both MToolkit _and_ XToolkit with JDK 1.5 successfully.  This problem is specific to XToolkit on Mustang, but XToolkit has much greater performance over the client-server link I'm attempting.  MToolkit is too slow to be a viable option.

Doesn't appear to be fixed for me? I'm running it wiht jdk1.6.0_10 on linux yet I still have the same problem.

uname -a
Linux lonrs05440 2.6.9-42.0.3.ELsmp #1 SMP Mon Sep 25 17:24:31 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux

/usr/local/qt/netbeans-6.5/bin/netbeans --jdkhome /usr/java/jdk1.6.0_10

I might add that I'm exporting the DISPLAY to Windows XP PC, using cygwinX with a 3 monitor setup.

This is a bug in your X Server, particularly using the Multi-Window mode. If you launch in any other mode Java menus (and all others) work just fine. I've seen it in Xming and Cygwin/X and I believe they run the same software underneath. If you try something other than Multi-Window mode you need to start a Window Manager as well (twm or fvwm) or you won't get any title bars or borders on your windows. -rootless mode is the clsoes thing to Multi-Window on an X Server. 

This page can be helpful in manually launching/configuring your Cygwin/X Server. 

http://x.cygwin.com/docs/man1/XWin.1.html#lbAJ