User Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/19.0 Firefox/19.0 SeaMonkey/2.16a1 Build ID: 20121009003041 Steps to reproduce: Browser window is not full screen and positioned on the right side of the display. The UI has some multi-level menus, some (at least) 3 deep, which will not fit on screen if they all open to the right. Depending on the length of the text in the menu items, either the second or third level menu will open to the left. This presented itself to me with both Bookmarks menus and the Web Developer add-on menu, the second level of Boomarks opening left (leaving the 3rd level to open right) and the third level of Web Developer opening left. Actual results: The 3rd level menu opens behind the 1st level menu, hiding much of the menu. Expected results: The 3rd level menu opens in front of the 1st level menu.

Can't seem to be able to duplicate in either Aurora or Nightly. What version of Web Developer are you running? See if the latest, 1.2.2, makes a difference? https://addons.mozilla.org/en-US/firefox/addon/web-developer/ Both Bookmarks & Web Developer are opening correctly. Default & Modern themes, Toolbars with pictures or not. Happen in a new, clean Profile with no extensions installed? Happen in a new Profile with only Web Developer installed?

therube, the particular menu is irrelevant, but placement of the browser window is. I just used Web Developer as an example because it was fairly compact and had nothing I felt was privacy related. The problem is exhibited for any menu, my bookmarks in particular. Here is a screenshot of my entire desktop, brand new profile, default bookmarks menu. 3rd level menu hidden behind 1st level menu. Placement of the browser window is on the right side of the screen with insufficient space to show all menu levels popping out to the right.

Much like how I was already testing, but still cannot duplicate.

You're running a Nightly. Does the same occur on Aurora or on the Release? Even though it was a new Profile, does restarting in Safe Mode make a difference? (Help | Restart with Addons Disabled) And further to that, if you disable Plugins. (Edit | Preferences -> Advanced => Enable plugins for, uncheck Suite) [may need a restart after that, & or a restart to re-enable plugins?]

therube, I know you are trying to be helpful, but it is not related to the profile, add-ons or plugins, and what happens on Aurora or a release isn't really relevant, since this bug is in a nightly. FYI, the issue shows itself on the Oct 9 build, but not the Oct 5 build. I'll download the Oct 11 build and see if it still occurs.

The problem starts with the Oct 9 build and is still present in the Oct 11 build. It is not present in the Oct 8 or earlier builds.

Can you check if the problem is also in Firefox? This sounds like a window manager bug or rather the way Gecko talks to the window manager.

Yes, it happens on the Firefox nightly from Oct 9.

I notice that even your level-2 submenu displays behind the level-1 menu (as shown on the left margin of the submenu) something which I cannot reproduce. I also notice that you seem to be using a third-party theme. Third-party themes (other than Personas) compatible with SeaMonkey 2.16a1 are extremely few and far between; in fact, AFAIK there aren't any at AMO. Please test in Safe Mode (Help → Restart with Add-ons Disabled) in order to check whether or not the same problem happens with the default theme, which is the only theme (other than Personas) which Safe Mode will use, and which is always officially compatible with the build with which it is distributed. Since this bug also affects Firefox, it might belong in Core; but it might also be due to the same error in two forked versions of a file, one in Firefox UI and a different copy of the same in SeaMonkey UI (and possibly a third one in Thunderbird UI) so I'm not moving it yet.

I was skeptical but started the Oct 9 build of Firefox in Safe Mode. To my surprise the issue went away. Ditto Seamonkey on both Oct 9 and Oct 11 builds. Maybe there is indeed a bad file that ended up in both forks. BTW Tony, you are mistaken on the 3rd party theme. I use the default Seamonkey classic theme with most of the toolbars and other UI elements disabled or hidden, and using text instead of graphics where possible. A couple of these are done via userChrome.css but most are from standard UI prefs. I do load the old mozilla icon set into the Seamonkey chrome folder because I like them better than the icons that come with the build. ;) Regardless, the issue presents itself with a brand spankin' new profile out of the box, which tells me my UI tweaks didn't cause this.

Hm. So it does happen in a brand new profile (where your enhanced preferences and userChrome.css tweaks are not present) but not in safe Mode (which also disables all of userChrome.css and some but not all preferences, and in addition sets the default theme). Strange. I think it is time to look up the Mercurial repositories for what changed between the nightlies of 8 and 9 October, but first, a little detective work to tell us which Mercurial changesets are involved. For a running build, the Nightly Tester Tools extension can tell us which comm-central (or comm-aurora etc.) was used for SeaMonkey, and the about:buildconfig page (in SeaMonkey or Firefox, or displayed as the Thunderbird Mail Start Page) gives us the mozilla-central (or mozilla-aurora etc.) changeset. For a non-running build, the same can be had from the *.txt file which sits next to the *.zip and *.installer.exe (for Windows), *.tar.bz2 (for Linux) or *.dmg (for Mac). You are on Windows so let's look up the changesets used by the Windows nightlies (they ought to be the same for W32, L32, L64 and Mac-Universal but let's not take any chances). October 8 (good): http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2012-10-08-00-30-26-comm-central-trunk/seamonkey-2.15a1.en-US.win32.txt 20121008003026 http://hg.mozilla.org/mozilla-central/rev/70337fa2fe62 http://hg.mozilla.org/comm-central/rev/f4e72212d200 October 9 (bad): http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2012-10-09-00-30-41-comm-central-trunk/seamonkey-2.16a1.en-US.win32.txt 20121009003041 http://hg.mozilla.org/mozilla-central/rev/aa5e3b445810 http://hg.mozilla.org/comm-central/rev/03fd0a59e409 ...and this already tells us that the problem happened at or near the watershed between 2.15a1 and 2.16a1. I'm still learning how to use Mercurial and its Mozilla implementation: I'm not sure how to search hg.mozilla.org for the differences between two given changesets but I could do it on my local Mercurial clone (it would, however, not give a URL that anyone could browse. Developers, your "last known good" and "good known bad" are the ones above in this comment.

oops... _first_ known bad; and there is a missing closing parenthesis at the end of the preceding paragraph. Let's get some more black tea.

output of "hg glog -r f4e72212d200::03fd0a59e409" in comm-central

output of "hg glog -r 70337fa2fe62::aa5e3b445810" in mozilla-central

Safe Mode also disables Hardware Acceleration (I'm pretty sure). So can't hurt to try started normally, but with Hardware Acceleration disabled. > Edit | Preferences | Appearance -> Content => Use hardware acceleration when available (uncheck) What Windows theme are you using? Classic, XP, some other? And still can't hurt to try with Plugins disabled.

Hmm. Focus issues due to Flashplayer plugin comes to mind. How about a test. Go to Tools->Addons. Disable all items in the Extensions tab, and Plugins tab. Restart.

Aha! The Hardware Acceleration pref is the key. After I disable it then restart the browser the problem goes away, regardless of what extensions or plugins are enabled/disabled. So does this mean there is an issue with the browser and my hardware? I think my graphics driver is up to date.

So what changed between Oct 8&9 (or 2.15/2.16) that could cause this?

> So what changed between Oct 8&9 (or 2.15/2.16) that could cause this? A lot changed between 08 and 09. I'll move this to Core. October 8 (good): http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2012-10-08-00-30-26-comm-central-trunk/seamonkey-2.15a1.en-US.win32.txt 20121008003026 http://hg.mozilla.org/mozilla-central/rev/70337fa2fe62 http://hg.mozilla.org/comm-central/rev/f4e72212d200 October 9 (bad): http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2012-10-09-00-30-41-comm-central-trunk/seamonkey-2.16a1.en-US.win32.txt 20121009003041 http://hg.mozilla.org/mozilla-central/rev/aa5e3b445810 http://hg.mozilla.org/comm-central/rev/03fd0a59e409 These are all the pushes between these two changesets. http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-10-07+20%3A54&enddate=2012-10-08+11%3A02

Bug 610713 gets my vote :)

(In reply to K Chayka from comment #20) > Bug 610713 gets my vote :) bug 610713 made two very small changes in the code, namely: - attachment #614934 [details] [diff] [review] landed 2012-04-16 as mozilla-central changeset 07f55ad76d8f - attachment #661084 [details] [diff] [review] landed 2012-10-08 as mozilla-central changeset 2d39dbbe75b3 This bug appeared on 8 October so the latter two-liner (in widget/windows/nsWindow.cpp) would be the culprit if the problem is indeed due to that fix. roc: what do you think?

That shouldn't affect window z-order, but it's probably the most likely candidate anyhow.