90823 - Relaunching or clicking Dock icon should display last minimized window or create new window

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[shoe_adam]

Close all Mozilla windows.  Click on the icon in the Dock.  Nothing happens.

A new window should open if none are open, and the Dock icon is selected.

Comment 1

[Adam Masri]

I was just about to post a new bug regarding this...

According to, "Aqua Human Interface Guidelines"

http://developer.apple.com/techpubs/macosx/SystemOverview/AquaHIGuidelines/AquaHIGuidelines.pdf

pp. 74:

o  clicking the Moz icon in the dock should bring forward all unminimized
application windows; minimized windows remain in the dock (we do this now)

o  if all Moz windows are minimized, the most recently minimized window should
be brought forward

o  If there are no open Moz windows, then a new window should be created (I'd
suggest a new browser window).

- Adam

Comment 2

[timeless]

.

Comment 3

[Adam]

I would hold on unminimizing windows. AFAIK, the only application that currently
does this is the Finder (probably because it's supposed to be a single-window
app). The other apps are smart enough to let the user decide what they want to
do with their windows. That might change with the 10.1 update if that part of
the Aqua HI guideline was recently modified, but I'd wait until then before
introducing this behavior.

Opening new windows by clicking on the dock icon should be equivalent to the
user pressing Command-N. All applications that I checked display this behavior.

Comment 4

[Adam Masri]

Uh huh. I've reported to Apple that this is a bug in their own software, since
it's in their own UI guidelines. We'll see what changes in 10.1, but IMO, this
is a valid bug and will continue to be. If this behavior was followed across
apps, it would be useful and expected behavior by the OS X community.

- Adam

Comment 5

[Bill McGonigle (not currently reading bugmail; please contact directly)]

If one wishes to see the specified behavior in action, OmniWeb implements it.  I find it to be the correct behavior (based on what I wish to do) more often than not. 

Comment 6

[Adam Masri]

It looks like in 10.1, Apple's software properly follows this Aqua convention.
For example, TextEdit, Terminal, and Internet Connect all do this now. I believe
this is here to stay, so it would be nice if Moz followed this rule too.

- Adam

Comment 7

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Could the implementor please ignore "Saving File" windows for this feature? If I
have only a "Saving File" window open there's no GUI for making a new window
(the          menubar is reduced beyond usability).  Clicking on the Mozilla
icon to get a new browser window is a very OSX-ish thing to do. 

Comment 8

[Mike Pinkerton (not reading bugmail)]

i agree we should raise the last minimized window, but i don't like the idea of
creating a new window. BBEdit does that on X and it annoys me to no end. I just
want to get to the menubar and it starts popping up windows.

How about we just do the former, not the latter? or leave that to another bug?
what do people think? taking over since dagley is on sabbatical.

Comment 9

[Mike Pinkerton (not reading bugmail)]

i agree we should raise the last minimized window, but i don't like the idea of
creating a new window. BBEdit does that on X and it annoys me to no end. I just
want to get to the menubar and it starts popping up windows.

How about we just do the former, not the latter? or leave that to another bug?
what do people think? taking over since dagley is on sabbatical.

Comment 10

[Mike Pinkerton (not reading bugmail)]

note to self:

from the Moon Travel sample code, use ::IsWindowCollapsed() and
CollapseWindow(wind, FALSE) to bring it out of the dock.

Comment 11

[Mike Pinkerton (not reading bugmail)]

tom had a good idea: if we need to open a new window, we should re-use the pref
we have for the window to open at startup. Most users won't have any idea of the
difference between open and re-open, so it lines up pretty well. Furthermore,
this gives users a way to turn this off (don't select any boxes).

He also convinced me that my BBEdit example was slightly flawed: most times when
you bring bbedit to the fg, you do want to open rather than create a new
document. However with navigator, the opposite is true. Users almost never open
an existing document and generally want a new window to browse in.

as a result, i'm dooming him to be on the cc list. 

Comment 12

[Andrew Thompson]

Pink let me see if I see how to do this:

(i) add a new Apple event handler for reopen (down in Apprunner, check I can do 
that)

(ii) ask the Window Mediator for windows of the appropriate kind (or perhaps all 
windows?), get the native window pointer and call IsWindowCollapsed on them to 
see if they are all docked or not

(iii) if windows exist other than the hidden window, and everything is docked, 
call CollapseWindow(wind, FALSE) on the first window that comes back from the 
Window Mediator (so long as its not the hidden one). Perhaps we should ignore 
dialogs like Preferences too?

(iv) if no windows are open make a new one of the appropriate kind (look at prefs 
service to see what sort of window the user wants opened, if any).

OK ... maybe I'll try to get this done, the only thing I don't know how to do is 
create a new window for mail/nav etc. Is it sensible to look in the document 
model for the appropriate menu items (they have ids?) and fire them?

Could do this all in C++ quite easily. Not sure it woudld benefit from any part 
being done in JS particularly...

How close am I?

Comment 13

[Mike Pinkerton (not reading bugmail)]

yeah, that sounds about right. Look at what the GURL event handler does to
create new windows. Not sure about mail, though. You can look at the code for
the 'initial windows to open' pref to see how they do it. Remember there may be
more than one checked.

Comment 14

[Mike Pinkerton (not reading bugmail)]

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

Comment 15

[Andrew Thompson]

I missed a step 

ii (a) if we have open, undocked windows, bring them *all* to the front (this is 
the current behaviour, its standard on Mac OS X, and it differs from simply 
clicking a window, which raises *only* that window)

QA should verify this behaviour is not lost when the other changes are made.

Comment 16

[Andrew Thompson]

Work in progress. Proper patch when I fix the three indicated issues. Basically 
works though...

/*----------------------------------------------------------------------------
	HandleReOpen 

	
----------------------------------------------------------------------------*/
void AEApplicationClass::HandleReOpen(AEDesc *token, const AppleEvent *
appleEvent, AppleEvent *reply)
{
	OSErr	err = noErr;
  PRBool haveUncollapsed = PR_FALSE;
  WindowPtr firstCollapsed = nil;
  
  nsCOMPtr<nsIWindowMediator> 
    wm(do_GetService("@mozilla.org/rdf/datasource;1?name=window-mediator"));
  if (!wm) {
    throw NS_ERROR_FAILURE;
  } else {
    nsCOMPtr<nsISimpleEnumerator> windowList;
    wm->GetXULWindowEnumerator(nsnull, getter_AddRefs(windowList));
    PRBool more;
    windowList->HasMoreElements(&more);
    while (more)
    {
      nsCOMPtr<nsISupports> nextWindow = nsnull;
      windowList->GetNext(getter_AddRefs(nextWindow));
      nsCOMPtr<nsIBaseWindow> baseWindow(do_QueryInterface(nextWindow));
		  if (NULL == baseWindow) {
        windowList->HasMoreElements(&more);
        continue;
      }

      nsCOMPtr<nsIWidget> widget = nsnull;
      baseWindow->GetMainWidget(getter_AddRefs(widget));
      if (NULL == widget) {
        windowList->HasMoreElements(&more);
        continue;
      }
      WindowRef windowRef = (WindowRef)widget->GetNativeData(NS_NATIVE_DISPLAY);
      if (!::IsWindowCollapsed(windowRef)) {
        haveUncollapsed = PR_TRUE;
        break;  //have un-minimized windows, nothing to do
      } else {
        //save the first collapsed window, in case we want to restore it from the 
dock later
        if (!firstCollapsed) {
          firstCollapsed = windowRef;
        }
      }
      windowList->HasMoreElements(&more);
    } // end while
    
    if (!haveUncollapsed) {
      //uncollapse the first window the mediator gave us
      if (firstCollapsed) {
        ::CollapseWindow(firstCollapsed, FALSE);
      } else {
        //didn't find any windows, make a new one
        
        
        //!! get the PREF service and open the right kind of window ...
        //either a browser, or mailnews or whatever
        
        nsMacCommandLine&  cmdLine = nsMacCommandLine::GetMacCommandLine();
		    err = cmdLine.DispatchURLToNewBrowser("");
       
       
       /* ********** REMAINING ISSUES ******************
       
          1/ Need to ignore the Hidden Window and any other such "invisible 
windows"
          
          2/ Need to use prefs service to figure out what to open
          
          3/ When restoring a window from the dock, make it come to the front
       */ 
      }
    
    }

  }
  NS_WARNING("getting re-open");

        // do stuff on startup that we want to do
        
	err = CheckForUnusedParameters(appleEvent);
	ThrowIfOSErr(err);
}

Comment 17

[Andrew Thompson]

Attachment: Patch to fix Dock Behaviour on Mac OS X

Why am I altering nsAppRunner.cpp? Because it has the functions I need to call
to open new browser windows, but it lacks a .h file so I cannot call them. The
common functionality I need has been moved to nsBootstrapHelpers.cpp, which I
will attach momentarily.

I'll be needing Windows and Linux build buddies for this one, I can see...

Comment 18

[Andrew Thompson]

Attachment: Seperated out functionality for opening new windows

Comment 19

[Andrew Thompson]

Attachment: .h for above

Comment 20

[Andrew Thompson]

I'm discussing this patch offline with pink and smfr. 

An additional query that's appropriate for this bug -> 

I think I should move the stuff I've been messing with in AppRunner out of 
AppRunner and put it somewhere it can be generally called, because its useful and 
if I implement Simon's suggested changes, I'll need to be able to call this stuff 
from inside widget.

I think xpfe/appshell is the right place? Maybe in command line ?

Comment 21

[Andrew Thompson]

See bug this depends on. Once that is in, I need to move this code into widget, 
so we're looking at completely new patches.

Comment 22

[Greg K.]

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

Comment 23

[Mike Pinkerton (not reading bugmail)]

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

Comment 24

[Andrew Thompson]

Not going to make 0.9.7, no traction on depends on bugs, or build process.

Comment 25

[Ari]

Displaying the last minimized window seems to be handled automatically by the
OS. If it were not for the hidden window, it would work on mozilla as well. In
my opinion, instead of heaping a new hack to simulate the OS default behavior on
top an old hack (the hidden window), I think that we should work toward getting
rid of the hidden window. This is already the second bug that I know of that is
caused by the hidden window and more may crop up because the hidden window uses
the window manager in way that it is not supposed to be used. See bug 71895.

Comment 26

[Dan M]

Yes, getting rid of hiddenwindow is a dream of mine. We've never considered
removing it on Mac builds, though, because it handily solves a bunch of other
problems with the Mac's unique menubar and windowless app structure.

Comment 27

[Matthew T (active 1999-2002)]

[Applies to all Mac OS versions, not just ones with Docks ... --> All]

Comment 28

[Bill McGonigle (not currently reading bugmail; please contact directly)]

How can 'Relaunching or clicking Dock icon should display last minimized window
or create new window' apply to OS's without Docks?  This should probably be set
back to OSX.

Getting rid of the hidden window is one way, and arguably an elegant way to fix
this bug, but it also seems like the most painful way.  Does anyone think that
would actually get done for 1.0?

On the other hand, lordpixel's already done quite a bit of work on getting this
bug fixed by his enhancements to nsAppShellService (which are good for other
reasons too), and it's just waiting for checkin as far as I can tell.

Maybe someone should make a bug for 'get rid of hidden window on Mac' or pile on
bug 71895, but marking this 'All' assumes this bug will be fixed by eliminating
Hidden Window (which might be a side effect in the future) but not fixing this
[really annoying] bug when there's good code to do it now seems silly.

Comment 29

[TVL]

> How can 'Relaunching or clicking Dock icon should display last minimized window
> or create new window' apply to OS's without Docks?  This should probably be set
> back to OSX.

The bahavior question also applies to a relaunch of the app from within the
Finder, and that is relavent for 8.x, 9.x and X.

As far as removing the hidden window "fixing" things, that might be true for
hidden windows on X, but I don't believe it's true for Collapsed (windowshade)
windows on the classic OSes.  Also, don't you have to directly handle opening a
new window if none are open on both classic and X?

Comment 30

[Andrew Thompson]

... yes this does apply to OS < 10 ... there's no dock but double clicking the 
already open icon in the Finder sends the same event... so a patch which fixes 
one fixes the other.

The only behaviour you get from OS X for free is if you click the app's icon in 
the dock all of its open windows come forwards (ie, like the old Mac OS 9 model)

There are 2 things standing in the way of getting this patch in.

1/ the nsAppShell stuff, which is stalled because noone seems able to come up 
with concrete objections or requirements. I'm sure it'll bitrot soon enough. 

I could implement this patch such that it does everything described *except for* 
opening a new window if none are open. That would half fix this bug and make it a 
lot less annoying. But...

2/ Simon objects to where the code is currently located (in addition to a couple 
of other review comments he gave me which I hope I can still recall). So it needs 
a new class to live in... I'll try to think more about that when I get time. This 
is a smaller problem than 1/ ultimately.

As for getting rid of the hidden window... its a nice idea, but to be honest its 
actually the solution Apple recommend for Java apps - use a hidden window. ( Java 
apps have a similarly Windows centric view of where menubars should go). So 
unless the whole Moz  architecutre behind windows and menus is changed, I don't 
see it happening. Of course, we could actually do that, whereas persuading Sun to 
change Java's design is a tough task indeed.

Comment 31

[timeless]

Please don't mark a bug All if it only occurs on MacOS, instead use the 
earliest os to which it applies.  The reasons: * BeOS runs on Macintosh 
computers. * Linux runs on Macintosh computers. * some BSD flavors run on 
Macintosh computers. * Darwin runs on Macintosh computers.  * None of those 
os's are affected by a bug specific to macos.

Comment 32

[adrian bellomo]

The Dock is a Mac OS X-only piece of user interface. Not Mac OS 8.5. 
Please, someone that can, correct this. I tried, but Bugzilla wouldn't let 
me.

Comment 33

[Andrew Thompson]

Yes there is no dock on anything before OS X but, if you had read the previous 
comments, you would have learned that the same thing should happen when 
applications are doubled clicked when already open on earlier versions of Mac OS.

Hence the title "Relaunching *OR*  clicking Dock icon ... "

Can we close this topic of discussion now ?

Comment 34

[adrian bellomo]

I'm sorry. I have been reading all the previous comments, because I am a 
CC of the bug. You're right that it applies to previous operating systems 
too.

Comment 35

[Bill McGonigle (not currently reading bugmail; please contact directly)]

There's still the unminimizing bit that's different for OSX.  I don't think
there's a classic analog (windowshaded windows don't get unshaded when an app
gets a reopen event).  If, as ajfeldman suggests, the OS is trying to unminimize
the hidden window on reopen, there would have to be an OSX ifdef to emulate the
unminimizing. 

I guess the title not being 'handle reopen apple event' is what confused a few
of us. ;)  There's really three parts (bugs?) then:  having a reopen handler
(all), making a new navigator window on reopen (all), and uniminmizing the last
minimized window (OSX).

But it's certainly not an 8.5-only bug...

Comment 36

[Andy Lyttle]

I'm a little confused as to why this bug might apply to classic Mac OS. 
Double-clicking the Mozilla icon in the Finder should bring the application (and
thus all windows) to the front (which it does), but should NOT open anything or
un-window-shade anything.  It might be a nice feature (which is why OSX does
it), but it is NOT standard behavior for classic Mac OS, and would be quite
surprising to users.

By the way, the comment about this being annoying in BBEdit is right on - it's
only annoying because when I click BBEdit, creating a new file is not what I
probably want to do.  With a browser, creating a new browser window is exactly
what I want to do, unless I've already got one open I can use.  Mozilla should
follow Apple's spec here.

Comment 37

[Adam Masri]

This is a "bug" only as it applies to OS X. This functionality is not defined
for OS 9.

Normally, when double-clicking the icon for an open application in OS 9, that
application comes forward. If that application was hidden with open windows,
they display in the exact same order they were in before the application was
hidden.  If that application had no open windows, a new window does not normally
open. If the application is quit, and I launch it, it should not necessarily
create a new window. Most apps don't do this in OS 9. Normally, an application
has a preference-- what would you like me to do when I'm first launched?

IMO, this bug is only about OS X. Why it's been changed, I don't know. I'm
setting this back to OS X only. Before anybody else changes it, please feel free
to read Apple HIG and point out why you're changing it to more than OS X. Feel
free to quote, list page numbers, URL's, etc.

- Adam

Comment 38

[adrian bellomo]

I think that this bug is most definitely a Mac OS 9 bug as well as OS X. I 
know that IE has this behavior, and it's very convenient. Netscape does 
not, and I think that Mozilla should implement it. Countless times have I 
been asked, "Why won't my Netscape open?!" (I am a tech support 
consultant at a business) and I show them that Netscape is actually open 
but there are just no browser windows open. Usually, if you double-click 
on a web browser, you want a browser window to open.

I cannot change the OS of this bug myself but I urge whoever can to make 
this a Classic Mac OS bug as well as OS X.

Comment 39

[Steve Dagley]

Yes, this is a Mac OS 8.x bug as well as a Mac OS X one.  Please don't change the 
OS field of this bug without following the complete thread of comments discussing 
why it's not just an OS X bug.  In summary - you will get a 'Reopen App' 
AppleEvent if you're already running under 8.6/9.x and your app is double clicked 
in the Finder (and I believe DragThing)  The expected behavior for document based 
apps is to open a new window if your app already doesn't have one open.

Comment 40

[Adam Masri]

Steve, of course I trust your judgement 100%. However, I disagree with you here.
This is not HIG compliant for MacOS 9. If you look through the MacOS 9 UI
specification, I do not believe you will find anything similar to this OS X
behaviour. The only OS 9 apps that automatically create a document window are
"one trick ponies" that have no other function. For example, calculator,
SimpleText. A few examples of apps that do not automatically create a new window
on startup:

1) PhotoShop (interestingly, Illustrator DOES automatically create a new window
on startup; I wasn't expecting to see that)

2) AppleWorks (Preference is set at default to open "Starting Points;" this can
be set to "None," in which case no window automatically opens at startup (since
AppleWorks wouldn't know which one you wanted to open)

3) Freehand

4) Quark XPress

5) Netscape 4 (opens browser window to last location it was in; if it was
closed, remains closed on relaunch)

If we get this behaviour in OS 9 "for free," there's nothing in Apple's manuals
saying it shouldn't be done. And even I admit that I get my fair number of tech
support calls from users that are confused by NS 4 behaviour. I guess what I'm
saying is that if getting this working on OS 9 is going to delay release of this
feature on X, then it really should be filed as a separate RFE. It's not a bug
on OS 9.

- Adam

Comment 41

[Steve Dagley]

Actually it is in the Apple docs but one that most folks overlook.  From Apple TN 
1102 - Mac OS 8:

>>>>>
Reopen Application Apple Event

Finder 8 now sends running applications a reopen application Apple event 
(kAEReopenApplication == 'rapp') whenever the user reopens the application. The 
purpose of the reopen application Apple event is to allow the application to 
provide visual feedback to the user.

User testing has indicated that when a user double-clicks on an application's 
icon, or in some other way causes the application to be launched, they expect to 
see some visual feedback that the application has in fact started and is ready 
for use. This visual feedback is often a new untitled document window or a 
document creation dialog when a document file has not been opened. Users 
associate this feedback with the action of double-clicking on the application 
icon.

It was discovered that when users double-clicked on the icon for a running 
application, and there was no visual feedback from the application (such as a 
document window or tool pallet), they would often think that something was wrong 
because nothing happened. Testing showed that the menu bar change (including the 
application menu icon) when the running application came to the front was not 
enough of a visual clue for novice users. They didn't realize that the 
application whose icon they had just opened was in the front ready for their use.

The idea behind sending the reopen application Apple event to the running 
application is to let the application know that the user has attempted to open 
it. When handling the reopen application Apple event, the application has an 
opportunity to provide visual feedback to the user. What the application does 
will depend on the application itself, and on the current state of the 
application. The action taken should also take into consideration any startup 
options the user has set in the preferences for the application.

In general, if no windows are open in the application, the action taken should be 
similar to what happens when the open application (kAEOpenApplication == 'oapp') 
Apple event is received after the application is launched. This could be opening 
an untitled document, or perhaps displaying a document creation dialog. If the 
application already has windows open -- be they document, tool pallet, dialog, 
etc. -- this will most likely be enough feedback and nothing further needs to be 
done.

Application frameworks should provide support for the reopen application Apple 
event. In many cases, the framework will be able to leverage the support it 
already provides for the open application Apple event. It could, for example, 
provide a global flag to indicate that the first Apple event has been handled at 
application startup time. After the flag is set, the open application Apple event 
handler would behave as the reopen application Apple event handler.
<<<<<

AFAIK this is the event the dock sends your app when you have no windows open so 
implementing support for it it makes it work in both OSes.

Comment 42

[Adam Masri]

OIC. I had no idea there was a TN for that. Umm, carry on, carry on... ;)

- Adam

Comment 43

[Steve Dagley]

Obviously didn't make 0.9.8 so retargeted to 0.9.9

Andy, any chance you're in a position to address the 2 blockers you mention in
<http://bugzilla.mozilla.org/show_bug.cgi?id=90823#c30>? 

Comment 44

[Andrew Thompson]

Ok, yes, this is a real bug bear for me because my personal debug build behaaves 
so much better than the regular moz builds. This pretty much annoys me once an 
hour with 0.9.8.

Steve, other than tracking DougT's recent apprunner changes in my build there's 
been no concrete progress on this.

After a discussion with Pink the other night, we have some ideas about the "code 
location" problem which are kinds covered in bug 115437. The apprunner stuff 
remains the sane... no further comments on bug 109811.

I guess what needs to happen is for me, Pink and Simon to have a quick talk about 
event sending mechanisms and decide whether its a good idea, or whether we just 
need some kind of nsIMacWindow interface. Then I could implement everything other 
than the new window behaviour.

For the new window stuff, I just need some consensus on where it should be and 
I'll move it there. But there are no concrete suggestions :(

I feel this needs direction from inside NSCP to co-ordinate a solution that's 
acceptable. Once  this is done, I'll code it as quickly as I can.

Comment 45

[Ken Harris]

I haven't used BBEdit, but what TextEdit does these days is create a new
(Untitled) window when you click the dock icon, but if you Open (or Open
Recent) before typing anything in it, it replaces that empty window with
the file you opened.

Mozilla isn't exactly a text editor, though, as somebody pointed out.
New Navigator Window sounds like a good default to me.

Comment 46

[Steve Dagley]

This isn't going to make 0.9.9 as lordpixel is otherwise occupied for a few
weeks.  Also bestowing the nsbeta1 keyword since it's one of the Mac bugs
identified as significant enough to merit fixing for MachV.

Comment 47

[timeless]

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

Comment 48

[Bruce Davidson]

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

Comment 49

[Gregory Pierce]

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

Comment 50

[Prachi Gauriar]

Is this going to be fixed by Mozilla 1.0? It definitely should be considering it
would make Mozilla more consistent with the OS and thus give it a better chance
of being well-received by Mac users.

Do the patches work?

Comment 51

[Andrew Thompson]

The real issue is bug 109881, which was at an impasse last time I was able to 
look at it.

I'll try to wake people up w.r.t. that sometime soon.

Comment 52

[Chris Casciano]

I'm sorry, but I don't follow. What does a tech evangelism bug about austrailian
government run toilets have to do with you getting this in for 1.0?

Did you mix up the bug numbers or am i missing something?

Comment 53

[Chris Casciano]

Err... disregard... i see from the dependancies that you did screw up the bug
number and it should have been bug 109811 and not bug 109881 in your previous post.

Sorry all for the spam.

Comment 54

[Paul Baker]

Reading the comments for bug#90823, it looks like there is a patch, but no one
has bothered to review it, which is a shame. Maybe everyone who has voted for
this bug should also vote for bug#90823 and hopefully then it will get the
attention it needs.

Comment 55

[Andrew Thompson]

OK, made some progress on this... this is mostly notes to self so I don't forget 
what to do next (its LATE).

1. when smfr reviewed on IRC he asked me to refactor code which finds the native 
window ref into a nice neat function (still TODO)

2. Have moved basic functionality out of nsAEApplicationClass into 
nsNativeAppSupportMac, nsAEApplicationClass now simply calls the implementation 
thru the AppShellService

These files need to be diffed and patched:

i/ nsAEApplicationClass - to remove functionality now in nsNativeAppSupportMac
ii/ nsNativeAppSupportMac - implement re-open functionality, implement 
nsNativeAppSupportMac as a class, provide creation function for this class 
(NS_CreateNativeAppSupport)
iii/ Add nsNativeAppSupportBase.cpp to apprunner.mcp so as we can build ii/
iv/ Edit nsAppRunner.cpp to ifdef out the default "do nothing" implementation of 
NS_CreateNativeAppSupport on Mac OS as we now have a real one in ii/
v/ Edit nsINativeAppSupport.idl to add the new ReOpen() function (or maybe create 
nsINativeAppSupportMac.idl for this and figure how to Query_Interface this out)
vi) Edit nsINativeAppSupportBase to have a default implementation of ReOpen() 
(unless we go the other way in v/)

3/ That'll get us the "unminimize the last window" functionality. As for "opening 
a new window when all windows are closed", that requires the depends on bug also. 
I might be tempted to comment out this part, so as to check in a partial fix to 
this bug and deal with the rest of this when bug 109811 is fixed (which might 
also involve moving some of that functionality into nsNativeAppSupport(Base|
Mac).)

OK - now I have an idea what I've done and what I'm doing next :)

Comment 56

[Chris Casciano]

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

Comment 57

[Chris Casciano]

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

Comment 58

[Chris Casciano]

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

Comment 59

[Chris Blackstone]

Shouldn't the OS of this bug be changed to Mac OS X since there is no Dock in
System 8.6?

I duped this bug yesterday cause I searched for Dock and Mac OS X.

Comment 60

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Chris - see Comment 29 and Comment 30.

Comment 61

[Paul Baker]

Reading over comment 41 where apple recommends that the program just behave
similar to the way it does when the app first opens, so doing that, when there
are no existing windows open, shouldn't it open whatever windows you have
selected in the Preferences/Appearance under "When Mozilla starts up, open...".
Obviously most people just have Navigator checked, but if for instance only Mail
is checked, shouldn't the reopen event cause Mail to open instead of a Navigator
window (depending on the prefs). Not sure how the current patch is coded. Just
my 2 cents.

Comment 62

[Andrew Thompson]

Yes. And this is what the current patch does, or at least will by the time I have 
this and and blocker bugs checked in.

Comment 63

[Andrew Thompson]

Attachment: Latest patch to fix reopen behaviour

This patch fixes the re-open functionality such that if all Mozilla's windows
are minimised and the user clicks on Moz's icon, the most recently used window
is unminized (un-window shaded on OS 9, I think).

It has the "open a new window" bit commented out, because the depends on bug
needs to be fixed before that can work.

To make this work, you need to add the existing file nsNativeAppSupportBase to
the apprunner codewarrior project. Naturally, the final patch as applied to the
tree will include diffs for this.

It incorporates some of Simon's stuff from bug 115437

Comment 64

[Steve Dagley]

Comment on attachment 81335 [details] [diff] [review]
Latest patch to fix reopen behaviour

r= with the caveat that all the {'s be on their own line to be consistent with
the bulk of the code (not to mention that being my personal preference :-)

Comment 65

[Andrew Thompson]

Attachment: Patch to apprunner.xml to go with above patch

This is the patch for apprunner.xml to add the extra file to the codewarrior
project. Use it together with patvh 81335

Comment 66

[Matthias Versen [:Matti]]

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

Comment 67

[Mark Chally]

What's the progress on this?  I see 1.0 final got built without it--a real pity,
as I agree with Prachi Gauriar, who believed it was an essential behavioral
issue for initial acceptance with Mac OS X users--and it drives me bats!

Comment 68

[Andrew Thompson]

Waiting for Simon Fraser to come back from sabattical. I'll try to move forward 
as I also want to see it fixed.

Comment 69

[Greg K.]

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

Comment 70

[Chris Blackstone]

This functionality works in Chimera/Navigator as of the 6-20 nightly. Can
anything be borrowed from that project to help out this bug?

Comment 71

[Prachi Gauriar]

Chris, I seriously doubt it. I'm betting the reason that Chimera works is that
it's built with the Cocoa APIs and Interface Builder, which gives that type of
thing for free.

Comment 72

[Paul Baker]

Carbon should provide a similar way of doing this since this is how ALL Mac apps
work (or at least they are supposed to) no matter whether they were written
using Carbon or Cocoa.

Comment 73

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Paul, Carbon does - it sends a reopen AppleEvent - Mozilla just doesn't handle
it as one would expect.  Check out what I wrote in comment 35.

Comment 74

[Prachi Gauriar]

Paul, what I'm saying is that due to the fact that Chimera is written using 
Cocoa, there probably wasn't any code written to handle the behavior this 
bug is describing, it just automagically does it... (hence, the "for free"). 

If an application is written using Cocoa's Document-based architecture, a 
lot of things like save/open dialogs, creation of new windows with proper 
titles, managing minimized windows, etc., are done for you without having 
to write any code.

Thus, I seriously doubt that any code can be borrowed from Chimera. 
There's probably no code written to begin with that addresses the issues 
in this bug.

Comment 75

[David Haas (gone, not reading mail)]

I'm not sure this is gonna help anyone with this bug, but just to clear
something up, it did take code in Chimera to make this happen.

In particular, it took the method
applicationShouldHandleReopen:hasVisibleWindow: in mozilla/chimera/MainController.mm

I doubt it can be borrowed.

Comment 76

[Greg K.]

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

Comment 77

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Somewhat related, but not really 'blocks': in bug 140582, which is about not
being able to make a new navigator window while downloads are going, the
work-around that's suggested (which makes that bug an enhancement, not a bug) is
to relaunch Mozilla from a shortcut. 

This bug is the Mac equivalant, so, in a way, this bug blocks users from being
able to do new activity once a download is going (with no other navigator
windows open).

I know I mentioned this back in comment #7, but I thought I should bring it up
again since bug 140582 didn't exist back then.

Comment 78

[Daniel Wang]

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

Comment 79

[nnooiissee]

Changing OS to MacOS X so that I could have found this easier. Any reason this
should affect Mac System 8.6 users?

Comment 80

[nnooiissee]

*Sigh* changing back to Mac System 8.6. Maybe All would be more apropriate?

Comment 81

[Bill McGonigle (not currently reading bugmail; please contact directly)]

nnooiissee, see comment #31.

Comment 82

[Simon Fraser [no longer active]]

Comment on attachment 81335 [details] [diff] [review]
Latest patch to fix reopen behaviour

Comments on attachment 81335 [details] [diff] [review]:

+#if 0
..
+#endif

Why leave the #if 0 code in there?

Other than that, sr=sfraser

Comment 83

[Benedikt Roth]

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

Comment 84

[Paul Baker]

Has this made it to the trunk yet? What are we waiting for now that it has
super-review?

Comment 85

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Looks like we just need a new patch without the #if 0 section and reviews on the
apprunner.xml patch so it can be marked fixed.

Should the depends on bug 109811 go at this point?

removed keyword: helpwanted

Comment 86

[qaz2]

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

Comment 87

[Andrew Thompson]

Just got back from vacation. Thanks to timeless for driving this through super 
review.

I'll try to update the patch sometime this week.

As for the #if 0 section, I'll have to check where that code came from, but I 
know I didn't add that preprocessor directive, so it probably came along as part 
of Simon's original patch - I just didn't notice it was redundant. I'll remove it 
and confirm everything is still OK.

re: the dependency on byg 109811 - that's still just as valid - this patch gives 
~80% of the behaviour we need, but for 100% you need 109811 too. (see comment 63) 
The cut down patch was intended to be a quick fix so it would stand a change of 
getting into 1.0 with much better behaviour. Best laid plans of mice & men, 
etc...

Comment 88

[Andrew Thompson]

OK, I confirmed this still works on the latest build.
I'll check in sometime this week, hopefully.

Do still need r/sr for the apprunner.xml patch, I think...?

http://bugzilla.mozilla.org/attachment.cgi?id=82432&action=view

Comment 89

[Darin Fisher]

Comment on attachment 82432 [details] [diff] [review]
Patch to apprunner.xml to go with above patch

rs=darin

Comment 90

[Andrew Thompson]

Approved patches are now checked in.

This bug should now be fixed in so far as un-minimizing the most recently used
window when all mozilla windows are in the dock is concerned.

This version will not open a new window if no windows are open, so I won't mark
it fixed yet. Need bug 109811 driven through to a conclusion before I can enable
that feature (which is working in my tree but disabled in the patch just checked
in).

Comment 91

[Jo Hermans]

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

Comment 92

[Andrew Thompson]

Attachment: Diff 2 additional files which should have gone into the above patch

Ooops. Missed a file from the patch above, which is why this, like, doesn't
actually work in the nightlies.

Attaching the missing bit.

Comment 93

[Blake Ross]

Comment on attachment 101065 [details] [diff] [review]
Diff 2 additional files which should have gone into the above patch

sr=blake

Comment 94

[Simon Fraser [no longer active]]

Looks good to me.

Comment 95

[Jo Hermans]

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

Comment 96

[Asa Dotzler [:asa]]

lordpixel, is this ready to land? It's on the 1.2beta buglist that drivers are
chasing. 

Comment 97

[Andrew Thompson]

Asa, its been checked into the nightlies since sept 30th.

The reason I haven't marked it fixed is there's a small piece left that I can't 
implement until bug 109811 is resolved. This is a 90% solution.

If you prefer I'll open another bug for the remaining 10% and mark this one 
fixed. It certainly should be in 1.2 as it stands.

Comment 98

[Asa Dotzler [:asa]]

No need for a newer bug. I'll just remove this from the 1.2beta tracking list. 

Comment 99

[Greg K.]

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

Comment 100

[nnooiissee]

Could we get this patch onto the 1.0 branch? This would have been a real nice
fix for NS 7.0.1, but no one seems to have noticed the nsbeta1 nomination.

Comment 101

[paul_findley]

Plesae note that the dock icon does not show the small black arrow when
navigator/chimera (what is the name, anyway?) is running. There is no way to get
a new window once all windows have been closed, short of a reboot! If you click
the icon, it tries to launch a second instance of the application, and then
gives an error message that only one can be running at a time. OS 10.2.3 on 7500
(xpostfacto install), chimera 0.6.

Comment 102

[Jonathan Louie]

comment 101, i think you have two chimera icons in your dock or something
because it works fine for me (chimera has black triangle indicator, launches new
window when clicked, chimera 0.6 macosx 10.1.5).  besides which, this bug
pertains to mozilla browser, not chimera. :)

Comment 103

[Chris Casciano]

Still not resolved in 1.3b/OS X?

Comment 104

[Dan Roca]

Yes, in Mozilla 1.3a, the behavior is still incorrect.

Comment 105

[Jo Hermans]

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

Comment 106

[Andrew Thompson]

Attachment: Patch to nsNativeAppSupportMac.cpp to enable new window opening

Patch completes fix for this bug by leveraging Conrad's Profile Manager work.

Clicking on Mozilla in Dock when no windows open will open windows specified in
preferences (a new browser window by default).

Comment 107

[Matthias Versen [:Matti]]

isn't OS Classic dead ?
BTW: You should add a person in your review request..

Comment 108

[Chris Casciano]

patch checked in last night & this does indeed look fixed in the build i id
shortly there after (setting to navigator or composer in prefs caused the right
window to open).

fixed anyone?

Comment 109

[Andrew Thompson]

Tested build 2003040708

Checked the test cases:

1) 

a/ Open 2 Mozilla windows,
b/ Drag a window from some other app ontop of both
c/ Click Mozilla in the dock
d/ All Mozilla windows come to the front, over the top of the window from the
other application

2)
a/ Make 2 Mozilla windows that are showing different URLs
b/ Minimize both Windows
c/ Click Mozilla in the dock
d/ The last minimized window de-iconifies itself (NOT the first window created)

3) 

a/ Close all Mozilla windows
b/ Click Mozilla in the Dock
c/ Windows open as according to Appearance tab in the preferences (ie, a new
broswer window by default)

Comment 110

[Chris Casciano]

I've filed bug 201146 on a slight extension of this behavior covering a case
that this didn't address (modal dialogs).

Comment 111

[Chris Casciano]

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

Comment 112

[Alfonso Martinez]

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

Comment 113

[Frankie]

v