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".

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

seems to be working now (2000 082708)

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.

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.

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.

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

RELEASE NOTE ITEM: above

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

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

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

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

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

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 case: 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:...

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

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

nav triage team: We should probably figure out what the behavior is and make it work. Marking nsbeta1, mozilla0.9

marking all. the problem will probably be fixed in nsapprunner or a related file, and probably affects linux.

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

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

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

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

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

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

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

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

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.

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 ); #endif + // 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. ***

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

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.

patch is wrong :-(. jag will explain. we need to observe some pref about new windows.

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: http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsAppRunner.cpp#339 or: http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/content/tasksOverlay.js#102

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".

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?

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

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.

That means we should read the user pref: user_pref("browser.startup.page", 2);

Right, and that's what nsICmdLineHandler's defaultArgs does in the browser's case.

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("browser.startup.page",(int *)&choice); if (NS_SUCCEEDED(rv)) { switch (choice) { case 0: // blank page case PageToVisit = "about:blank"; break; case 1: // home page case PageToVisit = "javascript:navigator.home()"; break; case 2: // last page viewed case prefs->GetCharPref("browser.history.last_page_visited",(char *)&PageToVisit); } else // if no pref, that means home page PageToVisit = "javascript:navigator.home()"; } (void)OpenWindow( "chrome://navigator/content/", PageToVisit );

Why not something simpler like: NS_NAMED_LITERAL_STRING(contractID, "@mozilla.org/commandlinehandler/general-startup;1?type=browser"); nsCOMPtr <nsICmdLineHandler> handler(do_GetService(contractID.get())); nsXPIDLString defaultArgs; if (handler) handler->GetDefaultArgs(getter_Copies(defaultArgs)); if (defaultArgs) OpenWindow("chrome://navigator/content", defaultArgs); else OpenWindow("chrome://navigator/content", "about:blank");

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.

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?

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, either. Patches welcome, though, as usual.

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(). 849a859,860 > // If all else fails, open new browser window. > (void)OpenWindow( "chrome://navigator/content/", 0 ); 1023,1029c1034,1050 < 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" ); > } 1034c1055 < 4, --- > args ? 4 : 3,

Mass moving most of mozilla0.9 bugs to 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? Gerv

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

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

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

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.

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

Resetting milestone to get these non-critical bugs off the radar till later this week.

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

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

Fix checked in.

Great, Bill. But this bug is now so confusing... what exactly does the fix _do_? Gerv

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

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

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

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

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

Nominating for catfood. This is a big problem in my opinion (especially when working on webpages in Dreamweaver for example)

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?

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

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 activity.

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

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 tcher;1")); + nsCOMPtr<nsIWindowWatcher> wwatch(do_GetService("@mozilla.org/embedcomp/windo w-watcher;1")); nsCOMPtr<nsISupportsString> sarg(do_CreateInstance(NS_SUPPORTS_STRING_CONTRAC TID)); if (sarg) sarg->SetData(args); 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.

sr=alecf on law's fix

a=asa (on behalf of drivers) for checkin to 0.9.

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

Fix was just checked in.

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. :(

Is this bug dependant on bug 59078 or bug 71895 ?

Well, as of build 2001051308 on W2KSP1, everything is working hunkey-dory again.

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].

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.

Same here with 2001060704 win98

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

Reopening since this is still a problem.

nav triage team: Looks like a dup of new bug 84664. Marking as such. *** This bug has been marked as a duplicate of 84664 ***

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.

sorry for the spam.

returning to the Verified Fixed state.