459535 - Seamonkey 2.0 alpha silently ignores -P option when Seamonkey is already running.

Status: RESOLVED DUPLICATE of bug 308076

(SeaMonkey :: Startup & Profiles, defect)

Description

[Jayson King]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b1pre) Gecko/20080924175508 SeaMonkey/2.0a1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b1pre) Gecko/20080924175508 SeaMonkey/2.0a1

In Seamonkey 2.0 alpha, the -P profile option is silently ignored if an instance of Seamonkey is already running, and a new window is opened with the running profile instead, even if the running profile is different from the requested profile.

No warning or error message is given to tell the user that the requested profile wasn't opened.

Reproducible: Always

Steps to Reproduce:
1. Start Seamonkey with -P profile_1
2. Start Seamonkey with -P profile_2
3.
Actual Results:  
A new window is opened in the running profile_1 instance.

Expected Results:  
An instance of profile_2 should be opened.

Previous versions of Seamonkey up to the latest official 1.1.12 release work as expected.

Comment 1

[Justin Wood (:Callek)]

As a temporary workaround...

seamonkey --no-remote -P profile_2

should work.

Though I suppose a warning of some-sort might be possible (I don't know this area of code well enough to know how hard that would be).

Comment 2

[Jayson King]

--no-remote would work except that if launching Seamonkey from a script or a link with --no-remote, it will *always* try to start a new instance with the requested profile even if one is already running, which will lead to an error.

Comment 3

[Jayson King]

I have learned about the -remote option, specifically, using -remote "ping()" to test if an instance is already running in a script.

So doing something like:

seamonkey -remote "ping()" -P $profile
if [ $? -ne 0 ]; then
    seamonkey -no-remote -P $profile "$@"
else
    seamonkey -remote "openurl("$@")" -P $profile
fi

works

HOWEVER, the -remote command is not mentioned in seamonkey --help in 2.0 alpha like it is in 1.1.x. Is it being removed?

Comment 4

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> Expected Results:  
>  An instance of profile_2 should be opened.
> Actual Results:  
>  A new window is opened in the running profile_1 instance.

This part is DUP of Bug 308076.
See Bug 308076 Comment #19 for brief history of "-remote" switch(which is already killed even on Linux), MOZ_NO_REMOTE=1 environment variable, and  "-no-remote" switch.

Comment 5

[WADA:World Anti-bad-Duping Agency]

When Firefox 3.0.3 is started twice(without -no-remote switch, with -P "prof_name"), following is issued in Error Console of first instance of Firefox.
> Warning: unrecognized command line flag -P
> Source File: file:///C:/...(snip).../firefox/components/nsBrowserContentHandler.js Line: 740
 (1) First process starts in "without -no-remote" mode, interpret -P,
     and uses the profile.
 (2) Second process knows "without -no-remote" then check for already started
     Firefox and pass parameters(-P: "prof_name") to the instance, then ends.
 (3) Because first instance is already running in "without -no-remote" mode
     using a profile, there is no need to handle -P: "prof_name".
Current logic seems to go to step of "unrecognized flag" in this case.
I think a warning at step (2) for existence of meaningless flag(switch) is kind for user, and "unrecognized command line flag -P" in this case is not so good. But I don't think these should be improved or corrected.

Comment 7

[WADA:World Anti-bad-Duping Agency]

Jayson King, Linux only request? (Platform:Linux is set)
If so, Bug 491295 for Core/Toolkit possibly resolves problem of "incorrect handling of -P switch by Seamonkey on Linux" too.
If you think "DUPing to bug 308076"(i.e. WONTFIX) is incorrect, please reopen bug, setting dependency to Bug 491295. 

(In reply to comment #3)
> HOWEVER, the -remote command is not mentioned in seamonkey --help in 2.0 alpha
> like it is in 1.1.x. Is it being removed?

Yes.
-remote was removed and "No -remote switch in 1.x" was replaced by MOZ_NO_REMOTE=1 on Linux too, and -no-remote was added for our convenience.
  -no-remote in Sm 2    <== No -remote switch in Sm 1.1
  No -no-remote in Sm 2 <== -remote with no additional data in Sm 1.1
Read bug 459638 comment #1, please.

Comment 8

[Jayson King]

>Jayson King, Linux only request? (Platform:Linux is set)

I set the platform to Linux because that is what I run. It may (or not...) be also the case on Windows. I don't know. I can try, sometime, if it would be necessary.

>If so, Bug 491295 for Core/Toolkit possibly resolves...

I will take a look at that bug (and its patch) in a bit. It looks similar.

Ok.

I am still reliably using the -remote switch as of 2.0b1pre, although you say it is being removed and it is not mentioned in --help.

Basically the functionality I am looking to replicate somehow, which was earlier (in 1.1.x) provided with simply using -P profile_name only (i.e. no -remote or -no-remote used), is as follows:

seamonkey -P profile_1 is expected to launch a window of profile_1. No matter if other instances with other profiles are running or not. If no instance of profile_1 is running, start one. If an instance of profile_1 is already running, then it (and only it) should open a window.

Basically, -P profile_1 should not cause a window of profile_2 to open. I have even seen where profile_1 is already running, yet launching seamonkey again with -P profile_1 will actually cause a fresh instance of profile_2 to start instead. I don't yet understand why. This is the case even when profile_1 is set to the default in profiles.ini.

Strangely, all works as expected as long as I use -remote. By taking out -remote, I do not get expected behavior.

This is what I have now, which works, and is similar to what I posted in another comment above:

seamonkey -P ${profile} -remote "ping()"
if [ $? -ne 0 ]; then
	MOZ_NO_REMOTE=1 seamonkey -P ${profile} "$@" &
else
	seamonkey -P ${profile} -remote "openurl("$@", new-window)" &
fi

Comment 9

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #8)
> Strangely, all works as expected as long as I use -remote.

It seems that data of "startup of Fx/Sm/Tb on Linux is consists of 2 stages, script and program" was lost from cheap memory in my brain... :-)
"-nomote ..." itself looks to be kept at least in Seamonkey 1(XPFE)/Seamonkey 2(probably Toolkit) on Linux.
(a) "-remote ..." is downgraded to hidden option?
(b) When Mozilla related documents were transfered to developer.mozilla.org and/or Mozilla Wiki, description about "-remote ..." is lost?
> https://developer.mozilla.org/en/Command_Line_Options

I seems to have misunderstood bugs around "MOZ_NO_REMOTE=1 on Linux" because of (b). Sorry for my wrong comments.