376216 - RemoteCommandLine does not use specified profile

Status: RESOLVED WONTFIX

(Toolkit :: Startup and Profile System, defect)

Description

[Andrew Schultz]

If I start up suiterunner and then invoke seamonkey (xpfe or suiterunner) on the commandline, it will pick up the suiterunner remote instance regardless of the profile specified.  I haven't poked at it yet, but the logical explanation would be that the X property for the profile name isn't getting set by the first instance.

Comment 1

[Andrew Schultz]

It seems toolkit makes no attempt to set the profile name atom.  It's easy enough to fix, assuming that's desirable.

Comment 2

[Andrew Schultz]

Attachment: patch

Comment 3

[Benjamin Smedberg]

Comment on attachment 260551 [details] [diff] [review]
patch

You cannot create multiple toolkitprofileservices.

Comment 4

[Serge Gautherie (:sgautherie)]

Copying from "Newsgroups: mozilla.dev.apps.seamonkey",
where Andrew wrote
[
Note that in spite of what I said in comment 1, it is not easy to fix. 
Toolkit startup does not even guarantee that something you might call a 
profile even exists.
]

*****

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/2007051411 SeaMonkey/1.5a] (suiterunner, tinderbox-builds) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070514 SeaMonkey/1.5a] (nightly) (W2Ksp4)
and MAS v1.7 and SM v1.0/v1.1 too.

Andrew,
is the behaviour different if you/Linux starts SeaMonkey first ?

For me/W2K, instance(s) without "no remote" option is always "shared":
no matter the applications/versions/profiles/order used/specified.

*(OS) Linux -> All.

Comment 5

[Caio Tiago Oliveira (asrail)]

Serge:

using only suiterunner,
open a profile named 'foo', then open a profile named 'baa'.
Then open the mail app for the 'foo' profile from the command-line, then open the mail app for the 'baa' profile for the command line.

Are you able?


If you don't use '-no-remote' it uses some instance, but you can't specify ***which*** instance.

If you specify a profile and don't use '-no-remote', it ignores the profile you specify.
If you do use '-no-remote', it will says the profile is already in use.


So "does not expose profile" is a nice description and it is valid.

Comment 6

[Serge Gautherie (:sgautherie)]

(In reply to comment #5)
> using only suiterunner,
> 
> Are you able?

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/2007051700 SeaMonkey/1.5a] (suiterunner, tinderbox-builds) (W2Ksp4)

I already said 'no' in comment 4
[
For me/W2K, instance(s) without "no remote" option is always "shared":
no matter the applications/versions/profiles/order used/specified.
]
and this was detailed by Neil and me in the newsgroup.

> If you don't use '-no-remote' it uses some instance, but you can't specify
> ***which*** instance.
> 
> If you specify a profile and don't use '-no-remote', it ignores the profile you
> specify.

Exactly, Windows will run 1 "remote/shared" instance (and profile) only: the first you start.

In other words, asking me is irrelevant since this regression/bug is Linux only [That's what I tried to ask in my previous comment] and I'm not using it.

> If you do use '-no-remote', it will says the profile is already in use.

SM says "in use" and sr says "not responding":
apart from the different message, that is not a suiterunner regression.

> So "does not expose profile" is a nice description and it is valid.

(I never said anything different.)

*(OS) All -> Linux.

Comment 7

[Andrew Schultz]

OK, the initial problem I was hitting got fixed in bug 251244 but what I described in comment 0 is still true.  What remains now is that RemoteCommandlLine passes nsnull as the profile name.  Pulling the -P parameter is complicated by the fact that CheckArg unconditionally gobbles the argument, so if remoting fails, SelectProfile won't see it.

patch to follow...

Comment 8

[Andrew Schultz]

Attachment: grab -P if specified

Comment 9

[Benjamin Smedberg]

Comment on attachment 276599 [details] [diff] [review]
grab -P if specified

toolkitprofileservice.selectedProfile doesn't actually work when it's in the regular toolkit process. You'll have to pass the name from nsAppRunner.cpp (but I thought somebody already wrote a patch for that, and I can't find it)

Comment 10

[Andrew Schultz]

Attachment: the real "grab -P if specified"

Sorry, wrong patch.

Comment 11

[Andrew Schultz]

Comment on attachment 276856 [details] [diff] [review]
the real "grab -P if specified"

>+  ar = CheckArg("p", PR_TRUE, &profileName, PR_FALSE);

*sigh*
This last PR_FALSE should be PR_TRUE

Comment 13

[Benjamin Smedberg]

Comment on attachment 276856 [details] [diff] [review]
the real "grab -P if specified"

I really don't think I want to take this functionality. It's very hard to test and is going to be fragile.