Menu positioning for root menus (ie. View menu) that would run off the bottom of the screen is not as good as Windows does it. Currently Mozilla just moves the menu up enough so it does not run off screen. Unfortunately, this makes it cover the menubar. A better positioning algorithm for root menus in this case is to draw the menu completely _above_ the menu bar (bottom of the root menu should butt up against the top of the menu bar) if there is more screen space available above the menubar than below it. If there is not more screen space available above the menu bar than below it, then the menu bar should be drawn below the menu bar, but cropped and menu scrolling function takes over (related to another unfixed bug). This is already done correctly by rods@netscape.com for his combo-box widgets. The rule behind the Windows menu behavior is that a child menu should not overlap it's parent menu - simple as that. This allows you to fully see both parent and child menus on screen (you want to see what context the child menu has come from), and allows you to easily go back to selecting a parent menu item (when a child is open) by moving the cursor over it - something which is harder to do if they are overlapping.

This also applies to submenus on top of parent submenus. In this case the horizontal positioning of a submenu needs to be considered if you are near the edge of the screen - submenus should not be moved on top of thier parents.

Taking menu/popup bugs.

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

bulk accepting xpmenu/popup bugs. sigh.

If someone wants to point me toward the code that ensures the menu is always on-screen (I think it happens somewhere after openPopup()), I'll try and take a run at this.

i'm working on this today as part of a fix for a pdt+ bug actually. trying to kill two birds with one stone. If i get stuck, i'll ping you though. thanks!

fixed.

Works for me (I wish I could mark bugs as Verified). It looks a little weird with the current chrome, though, as there is no border on the bottom of the menu bar items.

tested on winNT and linux [opt comm bits, 2000.03.03.08]. the parent (root) menus (eg, View or Bookmarks) no longer obscure the menubar, which is great. however, i do notice that opening a submenu can obscure the menubar. here's what i do (admittedly extreme example): 1. move the navigator window (assuming a new or vanilla profile) down far enough so that only the top 1 inch of its window is visible on screen. 2. bring up Bookmarks > Macintosh Resources submenu observe: the Bookmarks menu doesn't obscure the menubar, but the Macintosh Resources one does somewhat. 3. for an even more extreme case, further move the window as far right off the screen as possible. 4. repeat step 2. observe: the submenu covers a lot more of the menubar. btw, you don't need to move the nav window to such extreme positions if your profile has a huge bookmarks (where this would be a more common issue). in any case, i just want to know if this submenu issue is addressed in another bug, or still part of this one. thx.

on win32, at least, submenus are allowed to obscure the menubar.

I see that as well. It's just the first submenu that doesn't obscure the menu bar. I don't see the behavior described as being a bug.

thx for the info, pink (good to know that's expected behavior on win32). i wonder if this is also expected behavior on linux, but given the myriad window managers and themes one could choose from (eg, i use the Pixmap theme, with the Enlightenment wm on gnome), who knows? added pavlov to cc list to see if he has further thoughts on this... but verifying this for the nonce.