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

VERIFIED FIXED in mozilla1.2alpha

Status

SeaMonkey
UI Design
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: shoe_adam, Assigned: Andrew Thompson)

Tracking

(Blocks: 1 bug)

Trunk
mozilla1.2alpha
PowerPC
Mac System 8.6
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Don't set OS to "Mac OS X" or "All". See comments 30 & 31.)

Attachments

(1 attachment, 6 obsolete attachments)

(Reporter)

Description

17 years ago
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

17 years ago
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
Severity: enhancement → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Click on Dock icon should open new window → Clicking Moz icon in dock should display last minimized window in dock or create new window

Comment 2

17 years ago
.
Assignee: asa → sdagley
Component: Browser-General → XP Apps: GUI Features
Keywords: helpwanted

Comment 3

17 years ago
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

17 years ago
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
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. 

Updated

17 years ago
Blocks: 102998

Comment 6

17 years ago
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
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. 
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.
Assignee: sdagley → pinkerton
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.
Target Milestone: --- → mozilla0.9.7
note to self:

from the Moon Travel sample code, use ::IsWindowCollapsed() and
CollapseWindow(wind, FALSE) to bring it out of the dock.
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. 
Status: NEW → ASSIGNED
(Assignee)

Comment 12

17 years ago
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?
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.
*** Bug 108152 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 15

17 years ago
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.
(Assignee)

Comment 16

17 years ago
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);
}
Assignee: pinkerton → lordpixel
Status: ASSIGNED → NEW
(Assignee)

Comment 17

17 years ago
Created attachment 57145 [details] [diff] [review]
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...
(Assignee)

Comment 18

17 years ago
Created attachment 57146 [details]
Seperated out functionality for opening new windows
(Assignee)

Comment 19

17 years ago
Created attachment 57147 [details]
.h for above
(Assignee)

Comment 20

17 years ago
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 ?
(Assignee)

Updated

17 years ago
Depends on: 109811
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 21

17 years ago
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

17 years ago
*** Bug 110210 has been marked as a duplicate of this bug. ***
QA Contact: doronr → sairuh
*** Bug 109426 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 24

17 years ago
Not going to make 0.9.7, no traction on depends on bugs, or build process.
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Comment 25

17 years ago
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

17 years ago
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

17 years ago
[Applies to all Mac OS versions, not just ones with Docks ... --> All]
OS: MacOS X → All
Summary: Clicking Moz icon in dock should display last minimized window in dock or create new window → Relaunching or clicking Dock icon should display last minimized window or create new window
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

17 years ago
> 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?
(Assignee)

Comment 30

17 years ago
... 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

17 years ago
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.
OS: All → Mac System 8.5

Comment 32

17 years ago
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.
(Assignee)

Comment 33

17 years ago
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

17 years ago
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.
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...

Updated

17 years ago
OS: Mac System 8.5 → MacOS X

Updated

17 years ago
OS: MacOS X → Mac System 8.5

Comment 36

17 years ago
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

17 years ago
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
OS: Mac System 8.5 → MacOS X

Comment 38

17 years ago
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

17 years ago
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.
OS: MacOS X → Mac System 8.6

Comment 40

17 years ago
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

17 years ago
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

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

- Adam

Comment 43

17 years ago
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>? 
Target Milestone: mozilla0.9.8 → mozilla0.9.9
(Assignee)

Comment 44

17 years ago
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

17 years ago
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

17 years ago
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.

Keywords: nsbeta1
Target Milestone: mozilla0.9.9 → mozilla1.0

Comment 47

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

Comment 48

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

Comment 49

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

Comment 50

16 years ago
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?
(Assignee)

Comment 51

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
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.
(Assignee)

Comment 55

16 years ago
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

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

Comment 57

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

Comment 58

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

Comment 59

16 years ago
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 61

16 years ago
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.
(Assignee)

Comment 62

16 years ago
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.
(Assignee)

Comment 63

16 years ago
Created attachment 81335 [details] [diff] [review]
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
(Assignee)

Updated

16 years ago
Attachment #57146 - Attachment is obsolete: true
(Assignee)

Updated

16 years ago
Attachment #57145 - Attachment is obsolete: true
(Assignee)

Updated

16 years ago
Attachment #57147 - Attachment is obsolete: true

Comment 64

16 years ago
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 :-)
Attachment #81335 - Flags: review+
(Assignee)

Comment 65

16 years ago
Created attachment 82432 [details] [diff] [review]
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
*** Bug 146670 has been marked as a duplicate of this bug. ***

Comment 67

16 years ago
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!
(Assignee)

Comment 68

16 years ago
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

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

Comment 70

16 years ago
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

16 years ago
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

16 years ago
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.
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

16 years ago
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.
(Assignee)

Updated

16 years ago
Target Milestone: mozilla1.0 → mozilla1.2alpha
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

16 years ago
*** Bug 160258 has been marked as a duplicate of this bug. ***
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

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

Comment 79

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

Comment 80

16 years ago
*Sigh* changing back to Mac System 8.6. Maybe All would be more apropriate?
OS: MacOS X → Mac System 8.6
nnooiissee, see comment #31.
Whiteboard: Don't set OS to "Mac OS X". See comment 31.

Comment 82

16 years ago
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
Attachment #81335 - Flags: superreview+

Updated

16 years ago
Blocks: 168066

Comment 83

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

Comment 84

16 years ago
Has this made it to the trunk yet? What are we waiting for now that it has
super-review?
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
Keywords: helpwanted

Comment 86

16 years ago
*** Bug 170139 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 87

16 years ago
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...
(Assignee)

Comment 88

16 years ago
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

Updated

16 years ago
Attachment #82432 - Flags: review+

Comment 89

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

rs=darin
Attachment #82432 - Flags: superreview+
(Assignee)

Comment 90

16 years ago
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

16 years ago
*** Bug 170808 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

16 years ago
Attachment #81335 - Attachment is obsolete: true
(Assignee)

Updated

16 years ago
Attachment #82432 - Attachment is obsolete: true
(Assignee)

Comment 92

16 years ago
Created attachment 101065 [details] [diff] [review]
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.

Updated

16 years ago
Attachment #101065 - Flags: review+

Comment 93

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

sr=blake
Attachment #101065 - Flags: superreview+

Comment 94

16 years ago
Looks good to me.

Comment 95

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

Comment 96

16 years ago
lordpixel, is this ready to land? It's on the 1.2beta buglist that drivers are
chasing. 
(Assignee)

Comment 97

16 years ago
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

16 years ago
No need for a newer bug. I'll just remove this from the 1.2beta tracking list. 
No longer blocks: 168066
QA Contact: sairuh → petersen

Comment 99

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

Updated

16 years ago
Blocks: 180209

Updated

16 years ago
No longer blocks: 102998
Whiteboard: Don't set OS to "Mac OS X". See comment 31. → Don't set OS to "Mac OS X" or "All". See comments 30 & 31.

Comment 100

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
Still not resolved in 1.3b/OS X?

Comment 104

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

Updated

16 years ago
Blocks: 4252

Comment 105

16 years ago
*** Bug 195767 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 106

16 years ago
Created attachment 117047 [details] [diff] [review]
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).
Attachment #101065 - Attachment is obsolete: true
(Assignee)

Updated

16 years ago
Attachment #117047 - Flags: superreview?
Attachment #117047 - Flags: review?
isn't OS Classic dead ?
BTW: You should add a person in your review request..

Updated

16 years ago
Attachment #117047 - Flags: superreview?(sfraser)
Attachment #117047 - Flags: superreview?
Attachment #117047 - Flags: review?
Attachment #117047 - Flags: review+

Updated

15 years ago
Attachment #117047 - Flags: superreview?(sfraser) → superreview+

Comment 108

15 years ago
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?
(Assignee)

Comment 109

15 years ago
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)


Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 110

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

Comment 111

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

Comment 112

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

Comment 113

14 years ago
v
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite

Updated

10 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.