Closed Bug 204484 Opened 21 years ago Closed 20 years ago

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

Categories

(Firefox :: General, defect)

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

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: mstockman, Assigned: bugs)

References

Details

Attachments

(1 file)

all prefs
2.67 KB, patch
Details | Diff | Splinter Review 
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 206094 has been marked as a duplicate of this bug. ***
Summary: Activating Phoenix with no window open should open a new window → Activating Mozilla Firebird with no window open should open a new window
*** 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.
Assignee: blake → nobody
--> hyatt
Assignee: nobody → hyatt
QA Contact: asa
*** 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?
Assignee: hyatt → bugs
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
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?
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.
Attached patch all prefs — — Splinter Review 

    
    

    
  
> > 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.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED

    
    

    
  
verified fixed (see comments 23 and 24)
Status: RESOLVED → VERIFIED
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+
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

    
    

    
  
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
Status: REOPENED → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → FIXED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: