Closed Bug 50424 Opened 24 years ago Closed 23 years ago

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

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: jruderman, Assigned: law)

References

Details

(Keywords: regression, relnote, Whiteboard: critical for 0.9 - law looking)

Attachments

(2 files)

patch which goes to their home page instead of blank
658 bytes, patch
Details | Diff | Splinter Review
Added jag's suggestion (fixed up to compile OK)
1.43 KB, patch
Details | Diff | Splinter Review 
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
Assignee: asa → don
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
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.
Assignee: don → law
Target Milestone: --- → M21
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?)
Keywords: relnoteRTM
Whiteboard: relnote-user
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:...
Keywords: mostfreq
*** Bug 43270 has been marked as a duplicate of this bug. ***
*** Bug 62018 has been marked as a duplicate of this bug. ***
Keywords: mozilla0.9
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
marking all. the problem will probably be fixed in nsapprunner or a related 
file, and probably affects linux.
OS: Windows 98 → All
*** 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
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?

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

    
    

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

    
    

    
  
Fix checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
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..
Status: RESOLVED → REOPENED
Keywords: regression
Resolution: FIXED → ---
Whiteboard: relnote-user  will consider for 0.8.1 checkin

    
    

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

    
    

    
  
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
Keywords: relnote

    
  
Whiteboard: critical for 0.9

    
  
Whiteboard: critical for 0.9 → critical for 0.9 - law looking

    
    

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

    
    

    
  
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.  :(
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Is this bug dependant on bug 59078 or bug 71895 ?

    
    

    
  
Well, as of build 2001051308 on W2KSP1, everything is working hunkey-dory again.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 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].
Status: RESOLVED → VERIFIED

    
    

    
  
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

    
    

    
  
nav triage team:

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

*** This bug has been marked as a duplicate of 84664 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

    
    

    
  
sorry for the spam.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
returning to the Verified Fixed state.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: