JDK-4311449 : Need native grab for swing menus (cf. 4109607)
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2000-02-10
  • Updated: 2007-12-07
  • Resolved: 2007-12-07
Related Reports
Relates :  
JDK-4869100 - GTK L&F: ColorChooser: Java PLAF does not have "paint dropper"
Relates :  
JDK-5014550 - REGRESSION: JPopupMenu extending beyond JFrame does not stay up under KDE
Relates :  
JDK-6330494 - REG: JComboBox in an embedded frame unusable
Relates :  
JDK-4908345 - Menus of DeployTool (uses jdk1.4.2 - swing) stay active (on top) after another a
Description
Name: krT82822			Date: 02/09/2000


Classic VM (build JDK-1.2.2-W, green threads, sunwjit)

It is still not possible for a user to pop down a menu by clicking
outside the window containing the menu (for example on the desktop).

My understanding (from 4109607) is that this is not possible without
an enhancement to the runtime (4290715).  The person who worked on
4290715 incorrectly states that you can use the windowDeactivated
event to determine when to pop down the menu, but this does not work
on Unix systems when you have your focusPolicy set to pointer.

As a result it is still not possible for the swing people to implement
a fix for 4109607.  This results in no fix for at least the following
bugs:

4109607
4290715
4091869
4106331
4127064
4137341
4143416
4155684
4156858
4154103

Note also that 4109607 *is not* a duplicate of 4290715, it simply
requires that 4290715 be fixed before it can be addressed.
Please reopen both 4109607 and 4290715.
(Review ID: 99911) 
======================================================================
Comments
EVALUATION internal API has been provided for swing, and there is no reason to provide public API (nobody wants it). Thus I'm closing this CR as "will not fix", If someone wants such API feel free to submit new CR with appropriate motivation.
07-12-2007
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
01-10-2004
EVALUATION Fix in Tiger This problem also occurs on Win32 with Swing Heavyweight menus. Grab/Release is not the solution to this problem. richard.ray@eng 2000-09-11 Too late and too risky to fix in Tiger. ###@###.### 2003-07-30 I was able to implement abstract grab/ungrab functionality with UngrabEvent in case of automatic ungrab consistently on all toolkits. On Windows, the API is implemented using native focus/mouse listeners with some filtering. It has been decided to not use any hooks since many problems were discovered during testing. On X11 implementation uses XGrab* API. Currently, the API is private and resides in sun.awt.SunToolkit (grab/ungrab). sun.awt.UngrabEvent is posted when auto-ungrab happens on grabbing window (see javadoc for UngrabEvent for the cases when it is fired). To catch it, use AWTEventListener with WINDOW_EVENT_MASK. We plan to integrate private API into Mustang, and expose it as public API in Dolphin. ###@###.### 2005-05-26 12:19:39 GMT Private API has been integrated into the workspace. It is still in development, the future functionality depends on how Swing will use this API. We work with Swing team on improving the API.
01-10-2004
WORK AROUND Name: krT82822 Date: 02/09/2000 None ======================================================================
01-10-2004