Closed Bug 40109 Opened 24 years ago Closed 22 years ago

Ability to start two instances of mozilla

Categories

(SeaMonkey :: UI Design, enhancement, P3)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows NT
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 131805
Milestone:
Future

People

(Reporter: Marko.Macek, Unassigned)

References

Details

(Keywords: arch, helpwanted)

Since recent builds I am unable to start two instances of mozilla. This prevents me from having improved safety in case of a crash. I'd like to run mail and browser(s) in separate processes.
Same for me with Win95 2000052120. Never noticed it before, I guess, since I usually just open one instance and hit Ctrl-N for a new window.
grace, this sounds more like your areas, but am unsure of the component...profile management, perhaps? reassign where needed.
QA Contact: sairuh → gbush
Bhuvan, Isn't this the desired behavior- only one instance running with single profile? I checked bug 23952, which allows multiple instances from command line,- has it been fixed?
When I try to start another instance of Mozilla, I get nothing. No Mozilla window or other notification comes up. I don't see how this would be what's desired. Netscape will start up another instance if it is run again. I'm not sure of the IE behavior. (but I do know it at least brings up a new IE window)
wdormann is right. 4x does bring up multiple instances and as far as profiles concerned the (second time triggered) app simply uses the current profile in the run. Similarly any other instance there on. So, here we need logic that detects if the app is already running in order to use the current profile and skip displaying profile manager window. Adding Bill Law for the interfaces so that he can point us to the interfaces that detects whether an instance of app is already running... Secondly, there is another issue. If the user selects 'Profile Manager' from Start->Programs->Netscape6, then that operation should put up a dialog saying 'Quit communicator to run Profile Manager'. Should logic be located with the install script that runs this selection or should it just happen in the profile manager ..? Adding Samir to cc list on this issue.
Mozilla (on Windows) now detects if it is already running and if so, communicates with the running process. This should result in a new browser/mail/composer window opening. If that is not working, then a bug should be filed. I know there are some problems if the second instance is started by clicking on a desktop icon (this is another related feature that has recently been added). The default behavior must be to only run one instance of the application. There is already another bug (or at least discussion) related to providing the capability to override this (i.e., via a command line switch). I'm not entirely sure how advisable that is, however. I believe there are problems, or potential problems, if multiple processes are accessing shared data files. If somebody suggests a plausible command-line switch, it would be very easy to override the code that detects that Mozilla is already running. I'm going to accept this bug and hold it as a request to add support for said command-line switch. Please provide details on any scenarios where new windows don't open when they should and I'll fix those, too. Depending on what information emerges, I may split this into two separate bugs.
Status: NEW → ASSIGNED
Bhuvan, All the install script does is insert the flags to launch mozilla from the Start Menu. We do not leave any app behind that is capable of performing actions. I'm afraid that this will have to be a profile manager runtime chore.
thanks law and samir for updates. ok..all profile manager related concerns should be logged in the bug 23952.
We're not gonna fix this. It's a feature. Trust me.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
.
Status: RESOLVED → VERIFIED
*** Bug 45861 has been marked as a duplicate of this bug. ***
The current behavior is extremely counter intuitive. All the browsers I've used in the past have allowed multiple instances via a doubleclick from an icon. A lot of people are going to complain about this missing functionality.
I can run Netscape and Mozilla at the same time, and they're accessing the same files...
The problem wdormann hit (no new window coming up when double-clicking a desktop icon) is bug 50424.
Reopening. This facility is one I very much miss, because it is _extremely_ useful for tracking regressions and other QA. Having several builds running at once to compare behaviour is very useful. And, given that it's possible (so 'tis said) to bypass this code with a command-line option, I'd like it very much if that was done. If don doesn't want to run with this (would a "Pretty please" help? ;-), mark it helpwanted and assign it to nobody@mozilla.org. Gerv
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Law, since you expressed an interest in this bug, do you want it? Reassigning to vishy per syd. Marking Arch, Helpwanted, Enhancement, RFE.
Assignee: don → vishy
Severity: critical → enhancement
Status: REOPENED → NEW
Keywords: arch, helpwanted
Summary: unable to start two instances of mozilla → [rfe] unable to start two instances of mozilla
Blocks: 63004
Reassigning to myself.
Assignee: vishy → law
Severity: enhancement → normal
Summary: [rfe] unable to start two instances of mozilla → Unable to start two instances of mozilla
Severity: normal → enhancement
Summary: Unable to start two instances of mozilla → [RFE] Ability to start two instances of mozilla
nav triage team: Would be nice, but don't think we have time for this in beta1, marking nsbeta1-
Keywords: nsbeta1-
bug 63926 and brethren filed.
Depends on: 63926
oops make that bug 63925, 63926, and 63927. but especially 63925.
Depends on: 63925
No longer depends on: 63926
Isnt this a dupe of bug 50424?
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future
Duping this to bug 50424. *** This bug has been marked as a duplicate of 50424 ***
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
This bug is for the ability to run two separate instances, so it's not the same as bug 50424.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 81843 has been marked as a duplicate of this bug. ***
*** Bug 86062 has been marked as a duplicate of this bug. ***
*** Bug 89485 has been marked as a duplicate of this bug. ***
*** Bug 92356 has been marked as a duplicate of this bug. ***
This is very useful in certain situations. We set one cookie on a domain, and check for roles at the different web pages. For development reasons, we would like to keep our session ID's different, and can not do so with mozilla because we can only open one process. What would work great is if we could do the following: Start a new browser, authenticate, and get a "memory" cookie for your session id. If you start a second browser (not from the menu, or from a keyboard shortcut, but from trying to start a second instance of mozilla) your memory cookies are unique to that "session". here is a little flow: Open Mozilla (instance 0) Press Ctrl+N (instance 0) Try to open mozilla again, resulting in: Another Mozilla Window (instance 1) Press Ctrl+N (still instance 1) go back to first window, press Ctrl+N: Another Mozilla Window (Instance 0) I guess what I am getting at are logical instances in which you could seperate "memory" cookies, or anything else you wanted. We are only concerned with cookies.
*** Bug 105044 has been marked as a duplicate of this bug. ***
*** Bug 107154 has been marked as a duplicate of this bug. ***
On windows (win98, win2k, Gecko/2001101117 rv:0.9.5). I can run 2 instances of the profile manager (with the -P option) but the first (oldest) window inherits the profile of the later (newest) one. Cookies set running the second instance overwrite the first's cookies (so the applications I'm running as that user don't work anymore). Why is this bug's severity considered an enhancement when the real added feature that appears to interfere with new processes is the Profile Management? Isn't the separation of user settings and permissions a feature of an Operating System? Isn't the Profile Manager the "enhancement" and the ability to run a new process more of an expected behaviour, ie severity = major/critical? In my specific case applications I run are web based and require separate processes (and separate cookies) so I cannot use Mozilla in my regular workflow as a result of this problem. (And I speculate I'm not the only one.) what I see that is related: 23952 multiple instances of Profile Manager (and Seamonkey with same profile) may be started from command line duplicate: 34602 32112 detect if multiple instances of app is running duplicate: 8393 40109 [RFE] Ability to start two instances of mozilla duplicates: 45861, 63004, 61942 resolving this theoretically fixes: ....50424, 48352, et al.... all "mozilla icon/GUI response atypical" (my paraphrase) 63925 [RFE] enable Necko to run as a separate app. 40109+63925= 63926 [RFE] necko application MultiUser and MultiSession considerations 40109+63925+63926= 63927 [RFE] enable Necko to run w/o write privs. "necko- readonly"
For me too, the severity of this bug is major/critical. I need to start two different profiles at the same time. (one for mail/news and one for the web).
Blocks: 102947
reporter: would you like to pick one of the related bugs and start implementing it?
Assignee: law → nobody
Status: REOPENED → NEW
I am not sure if this is assumed/understood, but in the summary it states "2 instances of mozilla" and ideally the feature to have is a new process every time you click the icon/start mozilla from the command line--not just the ability to have 2. Internet Explorer does this: windows opened from the currently open one become child processes (inheriting cookies, etc) while clicking the icon starts a new process with its own separate cookies. When the processes end they (as I understand it) end in a series so that the last terminated process's cookie overwrites any cookie by the same name from a previous process.
we are so far from that world, its not even funny. This is very much a post-Mozilla-1.0 feature..
Obviously, 2 or more is ideal. But for now I'd just like to have one for browser and one for mailnews (I'd be even happy with having to use 2 different profiles for this, see bug 102947). If bug 102947 would be fixed, I'd just need a configuration for "mailto:" in browser and "http/ftp" links in mailnews to call the other copy of the program. I suspect this might even be doable for 1.0 or soon after. (I _might_ even have the time to work on linux implementation)
*** Bug 107938 has been marked as a duplicate of this bug. ***
*** Bug 113645 has been marked as a duplicate of this bug. ***
*** Bug 125931 has been marked as a duplicate of this bug. ***
*** Bug 141503 has been marked as a duplicate of this bug. ***
Summary: [RFE] Ability to start two instances of mozilla → Ability to start two instances of mozilla
*** Bug 186406 has been marked as a duplicate of this bug. ***
set MOZ_NO_REMOTE=1 put that in autoexec.bat or on NT, set the environment variable in control panel|system (or in a batch file before running mozilla) after doing that, all attempts to start mozilla will open a new instance. marking dupl. of the bug that implemented this. *** This bug has been marked as a duplicate of 131805 ***
Status: NEW → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → DUPLICATE
*** Bug 187167 has been marked as a duplicate of this bug. ***
verified
Status: RESOLVED → VERIFIED
*** Bug 187476 has been marked as a duplicate of this bug. ***
the current behaviour looks correct to me if you start mozilla without arguments. but, when starting mozilla with -profilemanager => it should display the profile manager and if the current profile is selected, just open a new window. if any other profile is selected, a new instance should be created. -P <profilename> => if a mozilla instance using the profile <profilename> is already running, that instance should open a new window. if not, create a new mozilla instance using profile <profilename>. at least, that looks logical to me. this should also work with arguments like -mail etc. i would like to either reopen this bug and correct the description or open a new bug.
please open a new bug for that
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.