JDK-4109607 : Need native grab for Swing Menus
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.0.1,1.0.2,1.1.5,1.1.6,1.2.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS:
    generic,solaris_2.5.1,solaris_2.6,windows_nt generic,solaris_2.5.1,solaris_2.6,windows_nt
  • CPU: generic,x86,sparc
  • Submitted: 1998-02-05
  • Updated: 1999-12-21
  • Resolved: 1999-12-21
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
   Everyone knows how to pop down (cancel) a menu.  You just click anywhere
outside the menu, and it goes away, right?  Not so with Swing menus, unfortunately.
Currently Swing menus only pop down if you click outside the menu but inside the
JFrame parent of the popup menu.  This is because the AWT does not provide a way 
to observe mouse events outside the java application's windows, leaving us no
way to find out (at the java level) that the user has clicked elsewhere on the 
desktop. As a result, swing applications feel 'different' from native apps.  
This is a BadThing(tm).

SUGGESTED FIX Proposed API change: =================== Add Toolkit.observeNextMousePressedEvent(Window, MouseListener) which observes the next mouse pressed event, wherever it occurs on the screen, and forwards it to the supplied mouse listener through the mouse listener's mousePressed method. The duration of the registration is one mouse pressed, if the app wants to listen for subsequent mouse presses, it needs to re-register the listener. It is important to note that the event is ONLY observed, it is NOT to be taken off the native (or java) event queue. Thus the 'intended recipient' of the event will still be notified, and it will not be possible to use this event for a denial of service attack.

EVALUATION georges.saab@Eng 1998-02-04 There are actually two problems to be solved for this RFE. First, there is currently no interface for tracking "cancel mode events", or events which should fire off under the following type of circumstances: 1) User clicks on an "outside of window" area. 2) User uses a key stroke combination that changes the foreground application. The behavior is somewhat platform-dependent. On some platforms, clicking on an "outside of window" area that is not part of an application in the background may not generate this event, for example. These events are not only necessary for pulldown menus, but for combo boxes, tool tips, popup menus, or anything else which needs to generate a popup window on top of an application window. The second problem is that there is no interface to track global mouse events. An application which may want to make good use out of the Robot API might need a way to track these, for example. I would highly suggest not using this as a solution to Swing's problem, since it does not take into account other ways to cancel popup windows, such as key strokes. Nevertheless, I feel there is legitimate grounds to develop this interface as well. michael.martak@Eng 1999-08-10