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 <http://bugzilla.mozilla.org/show_bug.cgi?id=90823> 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.

confirming. for point of reference this was sort of recently fixed on the Mozilla side with bug 90823

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

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

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

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.

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

reassigning mac bugs, sorry for the spam.

--> hyatt

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

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) { openNewWindow(); } 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.

*** 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 Safari.

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

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?

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.

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

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 ?

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 :)

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() http://lxr.mozilla.org/mozilla/source/xpfe/bootstrap/nsNativeAppSupportMac.cpp#308 which prints a message that it knows to open a new window and calls nsAppShellService::CreateStartupState( ... ) http://lxr.mozilla.org/mozilla/source/xpfe/appshell/src/nsAppShellService.cpp#1074 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.

> > 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?

Confirmed in build 20040120 (0.8+) on Mac OS X 10.2.8.

verified fixed (see comments 23 and 24)

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+

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?

WFM using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a2) Gecko/20040531 Firefox/0.8.0+ and Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040531 Firefox/0.8.0+ 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

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

So it has been asked so it shall be done Status -> FIXED Trunk and branch