When no windows are open, you can see the old Mozilla menubar instead of the Firebird menubar. - there are extra Window, Debug and QA menus - Firebird suddenly knows the cmd-1 shortcut, which doesn't work when a window is open - various menus can be seen which are sometimes usable, sometimes not. - ...

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030503 Mozilla Firebird/0.6

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

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

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

This problem is due to that "chrome://global/content/hiddenWindow.xul" which nsAppShellService::CreateHiddenWindow opens is old Mozilla version. We need new version of hiddenWidnow.xul for Mozilla Firebird. I suggest using not an overlay as we does today, but XUL preprocessor to create that file from "browser.xul".

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

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

kenji, what you say makes it seem to me (as a coder unfamiliar with mozilla code) that bug 206456 and bug 206936 and bug 206752 all share the same root cause as this bug. is that right? and if so, someone should do bugzilla magic to link them all together.

jonathan: Hmm, It looks bug 206456 and bug 206752 may have something to do with this, but bug 206936 seems different bug. Per bug 206456 and bug 206752, hiddenWindow.xul 's startup routine that is for SeaMonkey's can breaks correspondence of Mozilla Firebird browser windows' startup and shutdown routines. Should we make those bugs depends on this, though I'm not sure that yet? Someone has idea?

The same bug is also present in Thunderbird : bug 214228

Taking QA Contact as designated owner of Firebird-Menus. Sorry for bugspam.

reassigning mac bugs, sorry for the spam.

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

-> hyatt

Mapping out a plan of attack for this bug: (1) Add a new pref browser.hiddenWindowChromeURL that indicates what the URL of the hidden window is, so that Firebird and Thunderbird can point to their own hiddenWindows. (2) Use the XUL PP to include the menus shared by hiddenWindow into browser.xul for non-Mac platforms. (3) Use the XUL PP to place the menus into an overlay for Mac platforms, and then make the overlay be shared by hiddenWindow.xul and browser.xul in the Mac case only. This will also eliminate the race condition between hiddenWindow.xul and browser.xul that leads to an inactive window when you first launch.

Comment on attachment 129565 [details] [diff] [review] Implement support for a configurable hiddenWindow.xul file >+ rv = prefBranch->GetCharPref("browser.hiddenWindowChromeURL", getter_Copies(prefVal)); >+ char* hiddenWindowURL = prefVal.get() ? prefVal.get() : defaultHiddenWindowURL; hiddenWindowURL should be |const| to match the types of prefVal.get() and defaultHiddenWindowURL. Also... I can't tell whether prefVal.get() will return NULL or a pointer to an empty string in the case where the pref doesn't exist. If you're sure this does the right thing in that case, ok, otherwise you might change the test to prefVal.IsEmpty(). >+ printf("Hidden window is: %s\n", hiddenWindowURL); Get rid of the printf before you check in. r=bryner with those changes.

It does do the right thing. I tested both with and without the pref present.

Comment on attachment 129565 [details] [diff] [review] Implement support for a configurable hiddenWindow.xul file a=asa (on behalf of drivers) for checkin to Mozilla 1.5beta.

Fixed, and Firebird now has a hiddenWindow that matches. Keeping this open so I can do the remaining tasks, which include: (1) Disabling menu items that are inappropriate when no windows are open. (2) Repairing some of the commands so that they actually work (e.g., bookmarks).

Comment on attachment 129565 [details] [diff] [review] Implement support for a configurable hiddenWindow.xul file Landed this patch on the trunk.

David, might you rethink opening new bugs on the other tasks? I would have liked to have the "Mozilla menu bar appears" bug FIXED to dupe things against. (no, not a big deal, just with the total lack of builds it would have been cleaner on the triage side)

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

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6a) Gecko/20031029 Firebird/0.7+; Mac OS 10.2.8 The "File...Open File..." menu dialog does not appear when there are no open windows.

"open as tabs" for bookmark folders is missing when no windows are open.

Whatever the case, the core issue here is fixed. Please file a new bug(s) on commands that do not work when no window is open.

The Mac standard Cmd-~ still cycles through the hidden window, producing messages suuh as: ###!!! ASSERTION: invalid active window: 'Error', file ../../../../../src/embedding/components/windowwatcher/src/nsWindowWatcher.cpp, line 886 Break: at file ../../../../../src/embedding/components/windowwatcher/src/nsWindowWatcher.cpp, line 886 WARNING: getting z level of unregistered window, file ../../../../src/xpfe/appshell/src/nsWindowMediator.cpp, line 636 WARNING: getting z level of unregistered window, file ../../../../src/xpfe/appshell/src/nsWindowMediator.cpp, line 636

That's bug 168692. See also bug 150028 and bug 223545.