Build ID: 20000731008 M18 Don't know if this is a problem with menus themselves or what. The bookmarks menu need to appear on top of the Windows taskbar. It currently appears behind it; since I have enough bookmarks to make the menu scrollable, this is a major problem for me, as I can't access the rest of my bookmarks since the autoscroller appears under the taskbar (and is thus inaccessible). This basically renders the down autscroller unusable, as well as the majority of your bookmarks.

must fix for beta3. I was only able to access my first 9 bookmarks (after all those default preset folders) because of this.

WFM on win2k.

well it doesn't work on Win98. strangely enough, submenus don't seem to show the problem...

I saw this not work on claudius' machine. It works fine on trudelle's win98 box. Not sure what to do here, but not serious anyway. Futuring.

I don't understand how a user not being able to access more than 10 of his/her bookmarks isn't serious. But since there's a [pretty bad] workaround (sidebar bookmarks panel), and because the problem seems to be sporadic (it now wfm on win98), I'll leave it this way unless I can get some reproducible steps. (Why are you accepting bugs for slamm?)

Confirmed with (win98 2000080420) 1.click on an empty gray area of the taskbar. 2.click on bookmarks menu If you have a large amount of bookmarks the autoscroll is underneat the taskbar Note that if after clicking on taskbar you do alt+esc and then bookmarks it's over the task bar. IMO the best option is to make the bookmarks to span down to the bottom of the available area over the taskbar and not to the bottom of the screen overlapping the taskbar.

reassigning to matt and wondering why this wasn't done earlier in a mass change...

I have this problem in newest build too, build 2000091312. The situation even worse. The bookmark hide in the main browser windows. Check my screenshot page: http://www.kitkit.net/mozilla/mozillabug.html

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

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

This is a menus problem, surely.

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

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

The number of dups suggests that other people are seeing this. We really should address for beta1

This should be fixed asap. It prevents me from viewing more bookmarks and the only way to get around this is by opening a new window or by using the sidebar.

With NT4sp6a and Build 2001010404, clicking on the taskbar and opening the bookmarks menu does trigger the problem for me. alt+esc doesn't seem to fix it. New windows don't inherit the problem. Submenus behave in an interesting manner: clicking on the taskbar causes the last submenu I had open to exhibit this behavior from that point onward. Other submenus continue to work fine.

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

I think this bug should be fixed asap. Bugs dealing with appearance of the browser should be fixed asap because that's what people see first.

pepperxn: that was useless, if you want to fix this bug, feel free. bugzilla is an open forum where people come to report and fix incidents. If you feel a need to lobby please use something else [talk to a wall, visit irc, use a news group]. This problem is obviously reported so the next step is fixing it. pinkerton: sorry for the spam, do to the nsbeta1 nomination i'm marking -- in hopes of a real target.

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

i'll give this a try for 0.8

->moz0.9

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

Here's a patch, but after talking to danm, he suggested that Rod take a look: Index: nsWindow.cpp =================================================================== RCS file: /cvsroot/mozilla/widget/src/windows/nsWindow.cpp,v retrieving revision 3.319 diff -u -r3.319 nsWindow.cpp --- nsWindow.cpp 2001/02/23 02:02:33 3.319 +++ nsWindow.cpp 2001/02/28 02:49:11 @@ -1243,7 +1243,7 @@ ::ShowWindow(mWnd, mode); } else { DWORD flags = SWP_NOSIZE | SWP_NOMOVE | SWP_SHOWWINDOW; - if (mIsVisible || mWindowType == eWindowType_popup) + if (mIsVisible) flags |= SWP_NOZORDER; if (mWindowType == eWindowType_popup) { Basically, the old code would always set the NOZORDER flag when dealing with popups. This means that any call to ::SetWindowPos() would not change the zorder. If the user had clicked in the taskbar to make it the topmost TOPMOST window, this flag would ensure that we didn't come fully to the front and would remain behind the taskbar. Not setting this flag allows SetWindowPos() to work its magic and make sure our menu comes fully to the front. Rod? What say you?

kevin, cc'ing you because you were the one who added the SWP_NOZORDER flag for popups. I'm not sure why you did that, as it leads to the problem outlined in this bug. Can you r= this for me? rod and danm both looked at it and it looks ok to them.

Not, sure why I set this, but the change looks correct. r=kmcclusk@netscape.com

fixed.