Try this in the browser window: 1. Click on tbe bookmarks menu in the personal toolbar, so the menu pops down. 2. Click on the windowshade widget in the window frame (top right). Observer that the bookmarks menu remains suspended in space. It should go away, like it does if you resize or close the window.

Contextual bug; QA Assigning to self. This is probably related to 18721, in which clicking outside of an open contextual menu (on a menu bar) doesn't dismiss the contextual menu.

changed component and cc'ing self.

reproduced in today's opt comm bits. assigning to saari as p4 for m18

taking popup/menu bugs. I hate my life.

QA Assigning to Sarah.

BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus. XP Menus component will be deleted.

bulk accepting xpmenu/popup bugs. sigh.

I don't have a Mac, but on WinNT I can confirm that a non-client click dismisses any open menu. Hopefully this means that this bug is resolved as well. Anyone have a Mac?

windows and mac event handling code are totally different. win32 behavior would unfortunately give no insight into the mac working or not...

Right you are. Sorry, just trying to help.

just my $0.02 observation: on linux (using today's opt comm bits, 2000030108) my theme (Pixmap) allows for windowshading windows, so i tried this out. and, as on the mac, the popup remains displayed when the window is windowshaded. (other info: running the Enlightenment window manager, along with gnome; redhat 6.0, kernel v2.2.12-20.)

Mass moving M18 bugs to M19

I have this under Linux with fvwm2 configured to auto-raise windows: click to activate any menu, move the mouse out into a neighboring window (e.g. xterm), hold the mouse there and let the WM raise the other window. Now the menu appears on top of the other window. This indicates that under X11 at least, not all events which should cancel menus in fact do so. A FocusOut of the main window should always cause a menu or other popup to go away. Since all means of hiding a window also generate a FocusOut (at least under any sane WM) this would also fix the problem reported by S.E.V. Liberman.

mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-

*spam*: transferring current XP Menu bugs over to jrgm, the new component owner. feel free to add me to the cc list (unless am the Reporter) of any of these, if you have any questions/etc.

why people are talking about linux in a mac-only bug is beyond me. maybe they can file a new bug or something.... simon, any idea how we can detect the windowshade icon is being clicked? is it a new part code in the window manager? all the IM books i have are too old...

-> future

according to sfraser, we only get the inCollapseBox partcode under carbon. Until then, we're stuck with this.

I'm no Mac developer (and unfortunately haven't owned one for a number of years) but here's an idea. Can we capture when the window's size changes? If so, then we could do something like what's described at http://developer.apple.com/samplecode/Sample_Code/Human_Interface_Toolbox/Shadin gWinds.htm or http://x57.deja.com/getdoc.xp?AN=554760025&search=thread&CONTEXT=965076836.99057 6679&HIT_CONTEXT=965076738.990117907&HIT_NUM=1&hitnum=4. Basically, these say that if there's no content region for the window, then the window has been shaded.

Why is Mozilla recognizing these clicks? Don't windowshade until the popup menu has been closed. If a popup menu is open, you shouldn't be able to do anything until it's closed. One click, anywhere on screen, outside of the popup menu, should close the menu. Then you can windowshade away. I believe that is standard behavior - while the popup menu is active, nothing else is.

We have no control at the app level about clicks in the window shade widget. We just don't get the message (when not running under Carbon).

when we move to carbon, we can get a fix for this.

*** Bug 62500 has been marked as a duplicate of this bug. ***

not gonna happen in 098

we're not going to get a solution for os8/9, but for osx, this is taken care of by 99987 *** This bug has been marked as a duplicate of 99987 ***