Closed Bug 204418 Opened 21 years ago Closed 21 years ago

Firebird menu issues when no open windows exist on OS X

Categories

(Firefox :: Menus, defect)

Product:
Firefox
Component:
Menus
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firebird0.8

People

(Reporter: jo.hermans, Assigned: hyatt)

References

Details

Attachments

(1 obsolete file) 

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.
QA Contact: asa → bugzilla
reassigning mac bugs, sorry for the spam.
Assignee: blake → nobody
*** Bug 215172 has been marked as a duplicate of this bug. ***
-> hyatt
Assignee: nobody → hyatt
Status: NEW → ASSIGNED
Target Milestone: --- → Firebird0.7
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.
Attachment #129565 - Flags: review+
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.
Attachment #129565 - Attachment is obsolete: true
Summary: Mozilla menubar reappears when no open windows → Firebird menu issues when no open windows exist on OS X
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. ***
Target Milestone: Firebird0.7 → Firebird0.8
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.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
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.
QA Contact: bugzilla → menus
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: