When a user clicks on the desktop area in Windows or Solaris, there 
is currently no way to cancel visible pulldown, popup, or tool tip windows that 
are lightweight components. Two simple functions can be added to Component, 
grabCapture() and releaseCapture() to facilitate this. 
======================================================================

Add WindowListener for windowDeactivated to the parent container of the JPopUpMenu.  On the WindowDectivated invoke JPopUpMenu.setVisable(false)
 
  xxxxx@xxxxx   1999-12-22

Here's a workaround for pull-down menu:

frame.addWindowListener(new WindowAdapter() {
    public void windowDeactivated(WindowEvent e) {
        MenuSelectionManager.defaultManager().clearSelectedPath();
    }
});

  xxxxx@xxxxx   2000-06-21

Provided Work Around.

Refer to 4311449 for more evaluation.

The Workaround provided does not work in windowing systems that have an
implicit (pointer) keyboard focus policy.  These will generate
a window deactivated event whenever the mouse cursor
moves out of the parent window so the popup menu
will close too early.  If you haven't experienced this
then you have no idea how irritating it can be.

Note that I also entered this as a new bug over three weeks
ago but haven't had any response yet.

The workaround also doesn't work if you're using Win32: 
when the JMenu is up, click on the title bar of the current 
window. The current window will stay in focus, so you don't 
get any window deactivation events.

However, if you do the same with a native win32 menu, the 
menu will pop down, which is what the user expects.

A proper fix of this bug requires new AWT API. THIS IS A 
BUG. PLEASE RE-OPEN.

The workaround provided also doesn't work in a very common 
case. If the menu spills outside of the window, then 
selection will cause a window deactivation, the selection 
path will be cleared and the action will not be triggered. 
To reproduce, run the following program. Make the window 
large enough to contain the menu when pulled down and the 
action will get triggered. Make the window small enough so 
the pulled-down menu spills over and the action will not be 
performed:


    import java.awt.*;
    import java.awt.event.*;
    import java.beans.*;
    import java.util.*;
    import javax.swing.*;
    import javax.swing.event.*;
 
public class JavaTestApp
	{
    
    public static void main(String[] args)
    	{
    	JFrame frame = new JFrame("Frame");
    	
    	// setup a menu
    	JMenuBar menuBar = new JMenuBar();
    	JMenu menu = new JMenu("menu");
    	menu.add(new AbstractAction("Really long menu item 
that can spill over the window")
    		{
    		public void
    		actionPerformed(ActionEvent actionEvent)
    			{
    			System.out.println
("ActionPerformed");
    			}
    		}	);
    	menuBar.add(menu);
    	
    	frame.setJMenuBar(menuBar);
    	
    	frame.addWindowListener(new WindowAdapter()
    		{
    		public void
    		windowDeactivated(WindowEvent windowEvent)
    			{
    			System.out.println
("windowDeactivated received");
    			MenuSelectionManager.defaultManager
().clearSelectedPath();
    			}
    		}	);
    	
    	frame.pack();
    	frame.show();
    	}
    }

I too have problems with menus which extend outside the
frame and which cause the frame to get deactivated and I use
a window manager where the focus follows the mouse (KDE). I
think this should get fixed as well as the bug described in
this bug report: the closing of a menu by clicking somewhere
outside the application. This is common behaviour and users
request ist. Please reopen this bug.

Please re-open, work-around does not work for heavyweight 
components on Win32. (heavyweight in the sense that the 
menu extends outside of the border of the window).