JDK-4156858 : pulled-down menu doesn't unpost when window is no longer active.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.0.2,1.2.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 1998-07-13
  • Updated: 1998-11-03
  • Resolved: 1998-11-03
Related Reports
Duplicate :  
JDK-4109607 - Need native grab for Swing Menus
Duplicate :  
JDK-4154103 - One can interact with menus even when LightShow is in the background
Description
Run SwingSet. Choose "Menus & Toolbars". Click on any menu in the menu bar to pull it downu. Click in another unrelated window while the menu is down. The other window will activate, but the menu will remain down. Moving the mouse over the menu bar in the "inactive" window will pull down other menus.

On Solaris, this has the additional effect of leaving a "floating" the menu above an unrelated window, if that window happens to overlap as it activates.
To see this, run on Solaris and resize the SwingSet window to about 650x425. Activate another unrelated window (call it "window a") and move it so that it covers the Junk Food menu in the SwingSet window. Activate SwingSet again by clicking in its title bar. Click on Junk Food to pull down that menu. Click in window a to activate it and bring it to the top. Note Junk Food menu floating above window a.
Comments
EVALUATION I don't think this is as straightforward as it sounds. While it might be right to pop down menus in a user environment where deactivation of the window means that the user has clicked in another window, it is certainly NOT right in an enviroment where deactivation can be caused by the user moving the mouse outside the window. Think what would happen in CDE/Motif if the user has 'focus follows mouse pointer' -- the menus might be snached away because the usre navigated the menu hierarchy to a menu which lay outside the parent windows bounds! I think this bug should be withdrawn -- what do you say, Hania? georges.saab@Eng 1998-09-09 I disagree. Think of the concept of an "active window" as separate from "focus window". As long as a window is active, it's menus will stay up even if they are separate top-level windows -- in that case, they will even get focus, but, even in the point-to-type model, their active window "owner" will still have its title bar high-lighted (try it). The questions is what should happen once *another* window becomes the top-level window. On all systems that I know of only the active winodw can have menus that are pulled down. CDE seems to enforce in the point-to-type mode (for most apps, but not for Swing) by temporarily disabling point-to-type until either a menu selection is made and the menu is taken down, or the user clicks in another window and the menu is taken down. It might be interesting to find out how this is done, and perhaps use the same mechanism. In any event, we already have to be careful not to take down menus just because they loose focus (in the case of cascading heavy-weight menus, where all have to stay up even though only one of them can have focus), so I am not really understanding your argument. Perhaps we should get together and talk about this, but I think it's a pretty serious bug. N.B., this behavior also leads to another bug with point-to-type.Pull down a heavy-weight in point-to-type mode and then move the pointer to activate another window. The menu will stay up (that's what this bug report is about). Now, move the pointer back into the pulled-down menu without going through the window that owns the menu. You will be able to make selections from the menu, even though another window is active. This bug would be avoided if the other one was fixed (since the menu would have been taken down once its owner de-activated). hania.gajewska@Eng 1998-10-12 The mechanism for keeping the top-level window active while traversing menus is popping them down when another window becomes active is a grab at the native level. That is what disables point-to-type and allows the menu to pop down when the user clicks in another window. I already have an RFE for the AWT to give us a way to handle native grabbing (at least at some level), but unfortunately there is no way to do this currently without adding native code, and listening for focusLost is not the answer. I'm going to make this a dupe of the native grab request, because that is really what is needed to fix this bug. georges.saab@Eng 1998-11-02
02-11-1998