Activating Mozilla Firebird with no window open should open a new window




16 years ago
15 years ago


(Reporter: mstockman, Assigned: bugs)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



16 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030503 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030503 Mozilla Firebird/0.6

This bug was very recently fixed in Mozilla for OS X, so maybe the fix can be
picked up from there. See bug
<> for details.

Reproducible: Always

Steps to Reproduce:
My home page is about:blank, but I don't know if that's required or not.

1. Close all Phoenix windows.
2. Switch to the Finder.
3. Click the Phoenix icon on the dock

Actual Results:  
Phoenix activated.

Expected Results:  
Phoenix should have activated, and a new blank window should have appeared.

Comment 1

16 years ago

for point of reference this was sort of recently fixed on the Mozilla side with
bug 90823
Ever confirmed: true

Comment 2

16 years ago
*** Bug 206094 has been marked as a duplicate of this bug. ***


16 years ago
Summary: Activating Phoenix with no window open should open a new window → Activating Mozilla Firebird with no window open should open a new window

Comment 3

16 years ago
*** Bug 206628 has been marked as a duplicate of this bug. ***

Comment 4

16 years ago
Additionally even clicking File->New->Navigator Window won't create new window
if there are download windows open (all navigator windows are closed).

Comment 5

16 years ago
Tomi, the bug you're seeing I think is the "wrong menu with no windows" bug [bug
204418] and not this one (you don't get a new window in your cause because you
hit the command to open a new mozilla window... not a new firebird one)...

My hunch is these are two distinct problems.

Comment 6

16 years ago
*** Bug 213064 has been marked as a duplicate of this bug. ***

Comment 7

16 years ago
reassigning mac bugs, sorry for the spam.
Assignee: blake → nobody
--> hyatt
Assignee: nobody → hyatt


15 years ago
QA Contact: asa

Comment 9

15 years ago
*** Bug 222988 has been marked as a duplicate of this bug. ***

Comment 10

15 years ago
Should be very easy to fix. I usually only program in Java on MacOSX using the
Cocoa framework and there you have to register a NSApplication delegate and
whenever someone clicks on the dock icon, the method 

boolean applicationShouldHandleReopen(NSApplication theApplication, boolean flag)

is called. The really cool feature is that MacOSX already tells you if your app
has open windows or not! From the API doc:

flag indicates whether NSApplication has found any visible NSWindows in your
application. flag can be used as an indication of whether NSApplication would do
anything if you return true.

So my Java code would look like that:

if (!flag) {
return flag;

I guess not much different in C++
And "openNewWindow()" should be the same method that is called if the user
selects "New Window" from the File menu.

Problem: Download windows / bookmark manager windows / etc. will count as
windows, too. So if the user has a download window open, no new window will
appear either. But I could live with that for the moment. Better a quick fix
that works and later on a better fix, than having to wait three months for a fix.

Comment 11

15 years ago
*** Bug 225182 has been marked as a duplicate of this bug. ***
It'd be great to fix this one.  Now that we have a kick-butt default theme on
OSX, this is one of the most obvious useability flaws when comparing Firebird to

Having just read Hyatt's blog entry about goading in Bugzilla, I feel compelled
to add that I am already happily using Firebird.

Comment 14

15 years ago
Can we just copy SeaMonkey's code for this? SeaMonkey seems to do the right
thing.   This would be a good one to get for 0.8 given we're tryin' to make a
nice second impression on mac users with our pretty new theme.

Ben, can you add this to your list for 0.8? 
Assignee: hyatt → bugs

Comment 15

15 years ago
The bug described in 90283 seems at first glance to be identical to this bug,
but 90283 refers to Mozilla, where this has been fixed for two years; this bug
refers to Firebird, where the bug still exists.  

Comment 16

15 years ago
I'm nominating this for the 0.8 release bug fix because it's the ONE missing
feature that annoys me the most, and stops Firebird from being my default browser
Flags: blocking0.8?
Flags: blocking0.8? → blocking0.8+
I'm new to the nomination system.  Is there a way for people to second or
endorse a nomination?  

I set the block flag to +, but when reading the Help, that seemed to be the same
as approving it, which of course I can't do.  So I put the flag back to ?
Flags: blocking0.8+ → blocking0.8?

Comment 18

15 years ago
Just a question.  Forgive the ranting tone of this post.  What would it take to
get this bug fixed in 0.8, since someone has already submitted code to fix it? 
Does anyone have a clue?  In my experience, this is perhaps the biggest reason
Mac users don't like Firebird when I show it to them.  This particular behavior
is so anti-intuitive, it's ridiculous.  Picture a frustrated novice user who
clicks on the dock icon and sees *absoutely nothing*. They would quickly revert
to Safari or Internet Explorer, where clicking on the dock icon ALWAYS results
in a browser window appearing.  Mac people are ALL about the UI ande
ease-of-use, so if we want Mac people to take this broswer seriously, this must
be fixed -- it should be a top priority, even if the problem doesn't bother us
techies so much :) 

Comment 19

15 years ago
See my comment on Bug 212097.

In fact, the code needed to fix the problem as I see it is already
in Firebird.

Note nsNativeAppSupportMac::ReOpen()
which prints a message that it knows to open a new window and calls
nsAppShellService::CreateStartupState( ... )

Things get sticky around line 1089, when ChildCount( ) returns zero (there
being no children of 'general.startup'). This is probably due to the way
that the preferences are put together (No "When Mozilla starts, Start up
Navigator? et cetera).

This, I suspect is reflected in the all.js files in the two products.

Certainly they differ in that Mozilla has a
pref("general.startup.browser",             true);
in all.js and Firebird does not.

If you read the various bugs and discussions on this, you may feel
that more thought is needed before deciding how to approach this,
but a short term fix would be to alter the all.js for Firebird
on the above lines.

An immediate band-aid for an individual user, which does work
is to put that setting into 'user.js' in one's profile.

Is there any guidance anywhere on how to use a javascript
debugger to investigate problems like this?
making the change in user.js as ben fowler suggested works for me.

Comment 21

15 years ago
Created attachment 138189 [details] [diff] [review]
all prefs

Comment 22

15 years ago
> > This is probably due to the way that the preferences are put
> > together (No "When Mozilla starts, Start up Navigator? et cetera).
> Could you please explain what you meant by that? To me that sentence
> makes little sense. What is special about how the preferences are put
> together and why should Mozilla care when opening a new window
> (preferences are only read on program start)?

Good question.

1. I find that the preferences functions such as nsPrefBranch::GetBoolPrefs( ) 
and nsPrefBranch::nsPrefBranch( ) are called with great frequency during
the normal operation of Firebird.

2. By "put together" I meant the actual dialogue 
Mozilla Firebird -> Preferences ...
which in the case of the Traditional Mozilla allows one to choose whether
on startup the Mozilla should open (start) a browser, or a news window,
or e-mail or composer... I think that there are a total of six choices,
which are translated into the six children of general.startup . In the
case of Firebird there is no choice - it is just a browser - and so no
children of general.startup.

I worry that the CreateStartupState( ) is not a good 'solution' for Firebird,
and if I could I would suggest that the Reopen( ) operation is translated
into something that could be captured at the XUL/Javascript level and
handled without the need for (new) C++ code such as CreateStartupState( );

However I don't know enough about the Javascript architecture to express
an opinion; I am sure that if there is anyone reading this who does know.
it would be helpful to post a pointer to the relevant docs on the internals
of Mozilla. 
This appears to be fixed in the latest trunk (Jan 20, 2004) - can anyone else
confirm this?

Comment 24

15 years ago
Confirmed in build 20040120 (0.8+) on Mac OS X 10.2.8.
Last Resolved: 15 years ago
Resolution: --- → FIXED
verified fixed (see comments 23 and 24)
Flags: blocking0.8?
How about FIREBIRD_0_8_BRANCH? it doesn't seem to be fixed there! At least in my
latest nighty it does not. Is it still on Ben's list for 0.8? Would be nice.
*** Bug 233175 has been marked as a duplicate of this bug. ***
I fixed this on the branch.. last minute! heh. phew. 
This bug appears NOT to be fixed in the Firefox 0.8 source tarball and also not
in CVS using FIREFOX_0_8_RELEASE tag. Did Ben forget to check it in, but used it
for the official build? (there it is fixed...)
I double-checked and found out:
it is NOT fixed in FIREBIRD_0_8_BRANCH either (pull date 13.02.2004).
reopening as this is not fixed in Mozilla/5.0 (Macintosh; U; PPC Mac OS X
Mach-O; en-US; rv:1.8a) Gecko/20040426 Firefox/0.8.0+
Resolution: FIXED → ---

Comment 32

15 years ago
Weird. I tried this again with a new profile using a recent nightly build
(Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040504
Firefox/0.8.0+) and it appears to work fine, both by clicking the Firefox dock
icon and by double-clicking the Finder icon.

No new window opens if I command-Tab to Firefox, but I'm not sure it's supposed
to. BBEdit, for example, doesn't open a new window on command-Tab either.

I have noticed that if the Manage Bookmarks window is open (the way I usually
work), clicking the dock icon or double-clicking the Finder icon does *not* open
a new browser window, but that is probably correct behavior, too.

So why is this bug happening to some people and not others?

Comment 33

15 years ago
WFM using
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a2) Gecko/20040531


Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040531

Does anyone still see this... with a current build?
I'm not seeing this on either of my systems, running most recent 0.9 nightly.
I think we can mark this as FIXED

Comment 36

15 years ago
Confirmed working properly for Mozilla 1.7 and Firefox 0.9.1 on OS X.  I second
the FIXED suggestion.

Comment 37

15 years ago
So it has been asked so it shall be done

Status -> FIXED

Trunk and branch
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.