Run moz while moz is already running --> nothing happens



19 years ago
8 years ago


(Reporter: jruderman, Assigned: law)


({regression, relnote})

regression, relnote

Firefox Tracking Flags

(Not tracked)


(Whiteboard: critical for 0.9 - law looking)


(2 attachments)



19 years ago
This may be a Windows-only bug.  I'm using 2000 082508 on Win 98.

Steps to reproduce:
- Run Mozilla from a desktop link (with or without -console).
- Minimize and run Mozilla from the desktop link again.

Expected result:
A new browser window* opens to the start/blank page.

Actual result:
An hourglass cursor appears for a short time, but nothing happens.

* A few months ago Mozilla would start up a new instance, but recently (until a 
few days ago) it has been opening a new browser window using the existing 
instance.  I like the second way better because it seems to me that it would 
provide a nice way to implement bug 36283, "RFE: stay resident in order 
to 'load' faster".

Comment 1

19 years ago
This bug is either a dupe of bug 32112 (detect if multiple instances of app is 
running) or bug 48352 (can't run Mozilla if downloading a file). Either way, 
the basis of this is not to open another copy of Mozilla if one is already 
running, and I believe it was decided that the action was to remain like this.
-> XP Apps
Assignee: asa → don
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh

Comment 2

19 years ago
seems to be working now (2000 082708)

Comment 3

19 years ago
cc law, who fixed bug 32112.  this bug doesn't seem to be a direct result of 
bug 32112 because of when this started happening, but it's related.

Comment 4

19 years ago
Not dup of 32112, more like its evil twin brother.  That one complained that it 
actually used to do something.

There is a real problem here: we don't successfully activate an already-running 
Mozilla window, nor open a new one.  I'm not sure why that is, exactly but it 
probably isn't going to make nsbeta3.

Assigning to me, setting milestone to M21.  I suspect I've already got a bug on 
this lurking somewhere within Bugzilla.
Assignee: don → law
Target Milestone: --- → M21

Comment 5

19 years ago
If you drag something else onto the desktop onto the Mozilla shortcut while 
Mozilla is already open, it *does* open the shortcut.  Somehow this bug only 
happens when you double-click the icon by itself.

Comment 6

19 years ago
Draft relnote item:

Launching Netscape while Netscape is already running doesn't do anything.  
There are two possible workarounds for this problem.  The first is to click on 
an open Netscape window and press Ctrl-1 instead of trying to launch it again.  
If Netscape is for some reason still running but has no windows open, you will 
need to use ctrl-alt-del before you can open new Netscape windows using the 
shortcut.  The second workaround is to modify your shortcut by adding the full 
URL of your homepage or about:blank after netscp6.exe (but outside of any 
double quotes), so that all browser windows opened with the shortcut will start 
at that page.

(Is this bug Windows-only?)
Keywords: relnoteRTM
Whiteboard: relnote-user
*** Bug 59293 has been marked as a duplicate of this bug. ***

Comment 9

19 years ago
This is probably causing bug 48352, which has three dups.

Comment 10

19 years ago
*** Bug 48352 has been marked as a duplicate of this bug. ***

Comment 11

19 years ago
I wasn't aware of this bug. It is a duplicate of bug 40109.

Comment 12

19 years ago
Me and my big keyboard... this is NOT a dup of 40109. Sorry for the spam.

Comment 13

19 years ago
Ok, by dupes especially from bug 48352 this is mostfreq.

How many different cases do we have?

Could we solve this problem by changing mozilla's run behavior to do the 
following if it detects a current session:
find out what it defautls to loading
navigator. pretend that the command line was mozilla about:blank
messenger. pretend that the command line was mozilla javascript:...
multiples. pretend that the command line was mozilla javascript:...
Keywords: mostfreq

Comment 14

19 years ago
*** Bug 43270 has been marked as a duplicate of this bug. ***

Comment 15

19 years ago
*** Bug 62018 has been marked as a duplicate of this bug. ***


19 years ago
Keywords: mozilla0.9

Comment 16

19 years ago
nav triage team:

We should probably figure out what the behavior is and make it work. Marking 
nsbeta1, mozilla0.9
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9

Comment 17

19 years ago
marking all. the problem will probably be fixed in nsapprunner or a related 
file, and probably affects linux.
OS: Windows 98 → All

Comment 18

19 years ago
*** Bug 64089 has been marked as a duplicate of this bug. ***

Comment 19

18 years ago
*** Bug 64900 has been marked as a duplicate of this bug. ***

Comment 20

18 years ago
*** Bug 65333 has been marked as a duplicate of this bug. ***

Comment 21

18 years ago
*** Bug 65359 has been marked as a duplicate of this bug. ***

Comment 22

18 years ago
This bug might be related to bug 53952, "Mozilla won't start if another Windows 
app is frozen".

Comment 23

18 years ago
*** Bug 66429 has been marked as a duplicate of this bug. ***

Comment 24

18 years ago
*** Bug 67306 has been marked as a duplicate of this bug. ***

Comment 25

18 years ago
*** Bug 67399 has been marked as a duplicate of this bug. ***

Comment 26

18 years ago
Just to add a comment:

I recently encountered a situation where the documentated workaround did not
work. I had one Mozilla window open - a download status window.  IIRC, Ctrl-N
does not open a new window in that case.   The other workaround (CTRL-ALT-DEL)
would abort the download.

In this situation, I created an HTML file on the desktop, and opened it to get
another window.

This isn't working on build 2/5/2001. This seems like a really easy thing to
solve and I'm going to see if I can. If I am wrong then someone scold me. This
problem really annoys the heck out of me.

Comment 28

18 years ago
I'm quite sure I fixed it
here is a patch:

--- nsNativeAppSupportWin.cpp	2000/10/28 22:17:32	1.16
+++ nsNativeAppSupportWin.cpp	2001/02/17 10:05:24
@@ -847,6 +847,8 @@
             #if MOZ_DEBUG_DDE
             printf( "Unknown request [%s]\n", (char*) request );
+            // if all else fails, open a blank page
+            (void)OpenWindow( "chrome://navigator/content/", "about:blank" );
*** Bug 69188 has been marked as a duplicate of this bug. ***
Keywords: patch, review
*** Bug 69407 has been marked as a duplicate of this bug. ***

Comment 31

18 years ago
What's really cool is if this is fixed, you can start mozilla once and minimize 
it. Then, further clicks to the shortcut take only fraction of the time it takes 
to load initially.

Comment 33

18 years ago
patch is wrong :-(. jag will explain.  we need to observe some pref about new 
I kinda like the window.home() trick, but that will always take you to the
homepage, where the behaviour should follow the user's preference (see Edit ->
Preferences... -> Navigator).

One way to do this is to get the default arg for a browser window (blank page,
home page, last page visited) and pass that in, kinda like:


Comment 35

18 years ago
it should probably behave the same way as when one selects: file - new nav window

the behaviour should be settable in the prefs:

open new window to: 
  1. homepage (default)
  2. blank page
  3. same as current page
  4. this url .... < browse >
It currently shares the behaviour for "Page to load at startup".

Comment 37

18 years ago
then we need a new pref for "page to load on open new window"

ppl will likely want a different behaviour when their first loading the app
(homepage) from when their in the middle of doing something (open current page
in new window). agreed?

Comment 38

18 years ago
*** Bug 69511 has been marked as a duplicate of this bug. ***
I think this discussion should continue in a new bug. For this bug it's best to
write the patch to conform to the current behaviour, if later we decide to
change the behaviour we can update this patch or the checked in code.

Comment 40

18 years ago
The correct behavior here is whatever would normally happen when starting up 
Mozilla (load a new Navigator window showing to a blank page, to the home page, 
etc).  That way, double-clicking on the desktop shortcut for mozilla.exe will 
have the same effect whether or not the user happens to have another Navigator 
window open or not.

Comment 41

18 years ago
That means we should read the user pref:

user_pref("", 2);
Right, and that's what nsICmdLineHandler's defaultArgs does in the browser's

Comment 43

18 years ago
Perhaps something to the effect of this pseudocode:

            // if all else fails, open a page to spec
             nsresult rv;
             PRUint32 choice = 0;
             char * PageToVisit[255];
             PageToVisit = "about:blank";
             nsCOMPtr<nsIPref> prefs = do_GetService(NS_PREF_CONTRACTID);
             if (prefs) 
               rv = prefs->GetIntPref("",(int *)&choice);
             if (NS_SUCCEEDED(rv)) {
               switch (choice) {
               case 0:        // blank page case
                 PageToVisit = "about:blank";
               case 1:      // home page case
                 PageToVisit = "javascript:navigator.home()";
               case 2:      // last page viewed case
               } else       // if no pref, that means home page
                 PageToVisit = "javascript:navigator.home()";
             (void)OpenWindow( "chrome://navigator/content/", PageToVisit );
Why not something simpler like:

nsCOMPtr <nsICmdLineHandler> handler(do_GetService(contractID.get()));

nsXPIDLString defaultArgs;
if (handler)

if (defaultArgs)
  OpenWindow("chrome://navigator/content", defaultArgs);
  OpenWindow("chrome://navigator/content", "about:blank");

Comment 45

18 years ago
I've tweaked nsNativeAppSupportWin.cpp to simply reuse the logic elsewhere when
opening a "default" brower window.  The patch is mixed in with some other code;
I'll separate it and post it here ASAP.  Basically, I changed OpenWindow to
accept a 0 for "args" and pass one fewer argument to OpenDialog in that case.
That then triggers the prefs logic in navigator.js so it doesn't have to be
replicated here.

Comment 46

18 years ago
There is a case I encountered when I couldn't start mozilla when trying out 
patchs for this. If I had a release build open, I couldn't start a second copy 
of my debug build which made it hard to debug. Only one copy of mozilla at a 
time, is this what we want?

Also, while you are in that code, can you take a peek at bug 67720?

Comment 47

18 years ago
re: Only one copy of mozilla at a time (is that what we want?)

Of course, everybody wants something different :-).  There are problems running
multiple instances simultaneously (some of the code doesn't properly share
resources/files).  Independent of that, the code is designed to detect when a
copy is already running and simply pass the request to that other process.
That's by necessity (more or less) because otherwise the user would end up with
multiple instances running (due to double-clicking multiple times, for example).

I could envision YACLS (yet another command line switch) that would suppress the
current behavior.  I'm not sure how hard that would be to implement or how
urgent that is.

re: bug 67720: I see where we could put code to handle this, but
nsICommandLineArguments (or whatever its called) doesn't really support the
notion of more than one "URLToLoad."  I don't think that bug is a top priority,

Patches welcome, though, as usual.

Comment 48

18 years ago
Here's the extra tweaking I did.  Sorry it's not a real patch.  I have lots of
other changes in that file and don't have time right now to sort them out.  It
should be easy to figure out where these go.  The first chunk is slightly
modified from the original patch.  The other two go in OpenWindow().

>             // If all else fails, open new browser window.
>             (void)OpenWindow( "chrome://navigator/content/", 0 );
<             jsval *argv = JS_PushArguments( jsContext,
<                                             &stackPtr,
<                                             "ssss",
<                                             urlstr,
<                                             "_blank",
<                                             "chrome,dialog=no,all",
<                                             args );
>             jsval *argv;
>             if (args) {
>                 argv = JS_PushArguments( jsContext,
>                                          &stackPtr,
>                                          "ssss",
>                                          urlstr,
>                                          "_blank",
>                                          "chrome,dialog=no,all",
>                                          args );
>             } else {
>                 argv = JS_PushArguments( jsContext,
>                                          &stackPtr,
>                                          "sss",
>                                          urlstr,
>                                          "_blank",
>                                          "chrome,dialog=no,all" );
>             }
<                                                4,
>                                                args ? 4 : 3,

Comment 49

18 years ago
Mass moving most of mozilla0.9 bugs to mozilla0.8.1
Target Milestone: mozilla0.9 → mozilla0.8.1
I think there should be a prefs option to allow more than one copy of mozilla to
be open. Should I file this in a seperate bug?
law said: 
"Of course, everybody wants something different :-).  There are problems 
running multiple instances simultaneously (some of the code doesn't properly 
share resources/files)."

The most important use of this feature is running two separate Mozilla builds at 
once, for QA purposes. I would have thought the file sharing problems would be 
minimised in this case.

Is there any chance of this happening for 0.8.1, as it's targetted? Or is law 
too busy?

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

Comment 54

18 years ago
I'll add support for running multiple Mozilla's simultaneously as part of bug
53952.  You can already do that on Unix.  Mac won't let you (as far as I know).

Comment 55

18 years ago
It turns out my code doesn't have the desired effect (unless your pref says to 
open a blank page).

It appears that the only code that checks the pref to determine what page to 
open to is in the browser instance "command handler" GetDefaultArgs 
implementation (which seems a bit odd).

That code happens to match what jag proposes so I'm going with that.

Comment 57

18 years ago
3/13 patch looks ok to me, r=mcafee.

Comment 58

18 years ago
Resetting milestone to get these non-critical bugs off the radar till later 
this week.
Target Milestone: mozilla0.8.1 → mozilla0.9
*** Bug 72056 has been marked as a duplicate of this bug. ***
law, if you can get sr for this we'd like to see it make 0.8.1
-asa (on behalf of drivers)
Whiteboard: relnote-user → relnote-user will consider for 0.8.1 checkin

Comment 61

18 years ago
Got sr=hyatt (with request to change chrome urls to add a trailing "/").

Comment 62

18 years ago
Fix checked in.
Last Resolved: 18 years ago
Resolution: --- → FIXED
Great, Bill. But this bug is now so confusing... what exactly does the fix _do_?


Comment 64

18 years ago
>But this bug is now so confusing... what exactly does the fix _do_?

That's a very good question. While its correct to state that Mac OS 9 can't run 
two instances of the same application, the behaviour for what should happen if 
the icon is clicked while the browser is already loaded (rapp event) is specified 
(and we currently don't follow it)

I'll open a Mac specific bug unless people feel the details should be kept here?

Comment 65

18 years ago
Run moz while moz is already running --> *something* happens.

Simplest case is double clicking on the program icon (we're talking
Windows-only) when the program is already running.  Now, it will launch a new
browser window (to the page specified in your prefs: blank, home, or last-visited).

Comment 66

18 years ago
While testing this fix I noticed that maximized state wasn't being persisted 
correctly (bug 72558).  It looks like that's a separate problem that happens 
whenever the maximized window is also minimized.
lordpixel, did you ever file that mac-only bug? if so, bug 74251 should be dupped 
against it....
*** Bug 74780 has been marked as a duplicate of this bug. ***

Comment 69

18 years ago
Reopening...This seems to have regressed. Nothing happens when you double click
on the Mozilla icon on the desktop. or run another instance manually. Adding
regression keyword & Clearing Whiteboard..
Keywords: regression
Resolution: FIXED → ---
Whiteboard: relnote-user will consider for 0.8.1 checkin

Comment 70

18 years ago
*** Bug 40109 has been marked as a duplicate of this bug. ***

Comment 71

18 years ago
Nominating for catfood. This is a big problem in my opinion (especially when
working on webpages in Dreamweaver for example)
Keywords: nsCatFood
keyser: why is this a problem in dreamweaver? does it try to rerun the 
mozilla.exe executable with a new url and then that url never opens because 
mozilla is always running? 
Keywords: nsbeta1 → nsbeta1+
Target Milestone: mozilla0.9 → Future

Comment 73

18 years ago
Yup exactly. It does what it used to do which is show the Hourglass symbol for a
few seconds then do nothing. Its quite annoying.
*** Bug 76222 has been marked as a duplicate of this bug. ***

Comment 75

18 years ago
This has regressed further in the past day.  Whereas using builds of a few days
ago I could at least close all Moz then click a URL in another app (e.g.,
Outlook) to open the page, now even that does not work on 2001041704; that is, a
click on a URL now appears to do nothing on win32.

This one makes it rather more difficult to integrate Moz into the "flow" of

Comment 76

18 years ago
yes, that's because there was a bug to remove the hidden window and it was 
done. I hope 0.9 gets some workaround before release
Keywords: relnote


18 years ago
Whiteboard: critical for 0.9


18 years ago
Whiteboard: critical for 0.9 → critical for 0.9 - law looking

Comment 77

18 years ago
Simple fix (typo in contract ID):

Index: nsNativeAppSupportWin.cpp
RCS file: /cvsroot/mozilla/xpfe/bootstrap/nsNativeAppSupportWin.cpp,v
retrieving revision 1.19
diff -u -r1.19 nsNativeAppSupportWin.cpp
--- nsNativeAppSupportWin.cpp   2001/04/11 01:20:23     1.19
+++ nsNativeAppSupportWin.cpp   2001/04/18 22:03:08
@@ -1030,7 +1030,7 @@

   nsresult rv = NS_ERROR_FAILURE;

-  nsCOMPtr<nsIWindowWatcher> wwatch(do_GetService("@mozilla/embedcomp/window-wa
+  nsCOMPtr<nsIWindowWatcher> wwatch(do_GetService("
   nsCOMPtr<nsISupportsString> sarg(do_CreateInstance(NS_SUPPORTS_STRING_CONTRAC
   if (sarg)

I've got r=danm.

Somebody sr this and we'll get it checked in.
alecf, can we get your sr= on this please.  Thanks.

Comment 79

18 years ago
sr=alecf on law's fix
a=asa (on behalf of drivers) for checkin to 0.9.  

Comment 81

18 years ago
*** Bug 76646 has been marked as a duplicate of this bug. ***

Comment 82

18 years ago
Fix was just checked in.
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 83

18 years ago
Sorry to have to reopen this puppy, but it seems we have regressed.  On win2ksp1
build 2001051208 the bug is back in almost the exact form as originally
reported.  Moz is open on one page.  I minimize and find an html file in
explorer.  I double click on it.  Moz pops back to the foreground but the
double-clicked file is neither loaded in the current window or a new window.  :(
Resolution: FIXED → ---

Comment 84

18 years ago
Is this bug dependant on bug 59078 or bug 71895 ?

Comment 85

18 years ago
Well, as of build 2001051308 on W2KSP1, everything is working hunkey-dory again.
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
vrfy using 2001.05.29.09 comm bits on winnt --however, the page that appears in
the second browser instance is the default homepage [which makes sense to me].

Comment 87

18 years ago
With build 2001060704 on Windows 2000 SP2, when I try to launch Mozilla again
while it is still open, the currently open window goes to the home page instead
of Mozilla opening a new window. If I open an HTML document while Mozilla is
running, the document opens in a new window as expected.

Comment 88

18 years ago
Same here with 2001060704 win98

Comment 89

18 years ago
*** Bug 84856 has been marked as a duplicate of this bug. ***

Comment 90

18 years ago
Reopening since this is still a problem.
Resolution: FIXED → ---

Comment 91

18 years ago
nav triage team:

Looks like a dup of new bug 84664. Marking as such.

*** This bug has been marked as a duplicate of 84664 ***
Last Resolved: 18 years ago18 years ago
Resolution: --- → DUPLICATE
No, this is just plain wrong.  This bug was FIXED.  It should be remarked Fixed
or reopened with the newer bug duped against it.  It should not be reopened and
duped against a bug which is nearly a year newer.
Resolution: DUPLICATE → ---
sorry for the spam.
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
returning to the Verified Fixed state.
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.