491295 - Should respect -P commandline option when remoting command lines

Status: RESOLVED WONTFIX

(Toolkit :: Startup and Profile System, defect)

Description

[Kathleen :Brade]

We came across a problem with command line handling when using two Firefox profiles simultaneously.  Here are simplified steps to reproduce:

firefox -no-remote -P 1 &
firefox -no-remote -P 2 &
firefox -P 1 http://mozilla.org/
firefox -P 2 http://mozilla.com/

The expected result is that mozilla.org should be opened in the Firefox process that is using profile 1 and mozilla.com should be opened in the process that is using profile 2.

The actual result is that both urls are opened in the same Firefox process (the first process found is always used).

Looking in nsAppRunner.cpp, HandleRemoteArgument() looks for -P but RemoteCommandLine() does not.  This means that -P works with -remote but not for full command lines.

Comment 1

[Benjamin Smedberg]

This is a dup of either bug 441422 or bug 441035 and is WONTFIX in either case.

Comment 2

[Kathleen :Brade]

I don't think this is a duplicate of the bugs mentioned in comment 1.  My goal is to be able to run two copies of Firefox with two different profiles and then send command lines to them.  For that to work, the RemoteCommandLine() function needs to recognize the -P flag.  I will post a patch in a moment.

Comment 3

[Kathleen :Brade]

Attachment: Proposed patch

With this patch, I can now open two copies of Firefox (using profiles 1 and 2) by doing the following:
firefox -P 1 &
firefox -P 2 &

And then I can open the mozilla.org page in the Firefox process that is using profile 1 and the mozilla.com page in the other process with these commands:
firefox -P 1 http://mozilla.org/
firefox -P 2 http://mozilla.com/

Does this patch open up any security issues?

Comment 4

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> Platform : Linux

> firefox -no-remote -P 1 &
> firefox -no-remote -P 2 &
> firefox -P 1 http://mozilla.org/
> firefox -P 2 http://mozilla.com/
> 
> The expected result is that mozilla.org should be opened in the Firefox process
> that is using profile 1 and mozilla.com should be opened in the process that is
> using profile 2.

Because "-remote" switch is already removed even from Linux version, I write "-Remote-Mode" for current "No -no-remote switch" case. 
(Read bug 459638 comment #1, please) 

Above flow can be written as;
(1) firefox -no-remote   -P 1 &
(2) firefox -no-remote   -P 2 &
(3) firefox -Remote-Mode -P 1 http://mozilla.org/
(4) firefox -Remote-Mode -P 2 http://mozilla.com/

To Kathleen Brade(bug opener & owner): 

(Q1) AFAIK, Firefox running in "-no-remote" mode doesn't(possibly "cannnot" if MS Win) accept any request from remote.
Did former "-no-remote mode"(== No "-remote" switch) on Linux accept request from remote?

(Q2) On MS Win, only single instance of "-Remote-Mode" Firefox can exist in a system since very early stage of Mozilla. And, as Benjamin Smedberg says, bug 441422 or bug 441035 are already WONTFIXed.
Could multiple instances of "-Remote-Mode"(==No -remote switch of former versions)  Firefox exist in a Linux system before removal of -remote switch?

> And then I can open the mozilla.org page (snip)
> with these commands:
> firefox -P 1 http://mozilla.org/
> firefox -P 2 http://mozilla.com/

(Q3) Are you implementing "multiple instances of -Remote-Mode Firefox in a system"?
I thought Mozilla's basic design itself never prohibits it. And it seems correct...

(Q4) Your change will very easily produce confusions of general MS Win users. I think major reason of "removal of -remote switch" is to avoid such general user's confusions.
Is it Linux only change?
If no, is there any easy way to disable it?
If yes, please implement for MS Win, please.

Comment 5

[WADA:World Anti-bad-Duping Agency]

Additional question to avoid my mis-understanding.
(Q5) "firefox -Remote-Mode/-no-remote -P profile-X url" is NOT "remote request"?
     It's "Open of url from command line at Firefox running with -P profile-X"?
(Q5-a) If so, "-Remote-Mode Firefox using profile-X" and "-no-remote mode
       Firefox using profile-X" are simply considered "Firefox who is
       running with profile-X"? Or isolated?
(Q6) Priority of parameters: "url > -P profile-X > -Remote-Mode/-no-remote "?
  I thought semantically "-Remote-Mode/-no-remote > -P profile-X > url".
  So, I thought meaning is "start of Firefox in -Remote-Mode or -no-remote mode,
  using profile-N, and open url.
(Q7) -no-remote is currently shortcut of "setting environment variable of MOZ-REMOTE=1" (Because of "forcing MOZ-REMOTE=1 & removal of -remote switch even on Linux", -no-remote was implemented for our convenience).
Is behavior of "firefox -P profile-X url"+MOZ-REMOTE=1 and "firefox -no-remote -P profile-X url" is same after your change?

Comment 6

[WADA:World Anti-bad-Duping Agency]

FYI.
Bug 459535 is similar bug to this bug for Seamonkey 2, and was closed(on 2008-10-13) as DUP of Bug 308076(closed as WONTFIX on 2006-05-24).

Comment 7

[Kathleen :Brade]

(In reply to comment #4)
> (Q1) AFAIK, Firefox running in "-no-remote" mode doesn't(possibly "cannnot" if
> MS Win) accept any request from remote.
> Did former "-no-remote mode"(== No "-remote" switch) on Linux accept request
> from remote?

Yes.  Looking at the implementation, the presence of -no-remote only determines whether Firefox looks for an already running process to send the command line to.  I think of "-no-remote" as "don't reuse an existing process."


> (Q2) On MS Win, only single instance of "-Remote-Mode" Firefox can exist in a
> system since very early stage of Mozilla. And, as Benjamin Smedberg says, bug
> 441422 or bug 441035 are already WONTFIXed.
> Could multiple instances of "-Remote-Mode"(==No -remote switch of former
> versions)  Firefox exist in a Linux system before removal of -remote switch?

I'm not sure about MS Win.  This is a Linux-specific (Linux-only) fix.  I don't know how Firefox behaved before -remote switch was changed.


> (Q3) Are you implementing "multiple instances of -Remote-Mode Firefox in a
> system"?

Yes, as long as different profiles are used for each process.


> (Q4) Your change will very easily produce confusions of general MS Win users. I
> think major reason of "removal of -remote switch" is to avoid such general
> user's confusions.
> Is it Linux only change?

Yes, it is a Linux-only change.  Why would it cause confusion to MS Win users?  The only change I am proposing is that the -P option is used when looking for an existing Firefox process to send commands to.


> (Q5) "firefox -Remote-Mode/-no-remote -P profile-X url" is NOT "remote
> request"?
>    It's "Open of url from command line at Firefox running with -P profile-X"?

Yes, that is how I want it to work.  It is both surprising and limiting that -P is ignored.

> (Q6) Priority of parameters: "url > -P profile-X > -Remote-Mode/-no-remote "?
>   I thought semantically "-Remote-Mode/-no-remote > -P profile-X > url".
>   So, I thought meaning is "start of Firefox in -Remote-Mode or -no-remote
>   mode, using profile-N, and open url.

I don't think that there needs to be a priority as you describe.  Firefox should pay attention to all parameters that make sense.  The code does need to look for the presence of -no-remote early so that it can skip looking for an already running process.


> (Q7) -no-remote is currently shortcut of "setting environment variable of
> MOZ-REMOTE=1" (Because of "forcing MOZ-REMOTE=1 & removal of -remote switch
> even on Linux", -no-remote was implemented for our convenience).
> Is behavior of "firefox -P profile-X url"+MOZ-REMOTE=1 and "firefox -no-remote
> -P profile-X url" is same after your change?

Actually the environment variable is MOZ_NO_REMOTE=1.
The behavior should be the same since the code checks the environment variable before calling RemoteCommandLine() which is the function I changed.

Comment 8

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #7)
> > (Q2) On MS Win, (snip)
> I'm not sure about MS Win. This is a Linux-specific (Linux-only) fix.

I see. I don't care for Fx, because Mozilla Company seems to hate Profile Manager(see Bug 214675 : Remove Profile Manager UI).
Kathleen Brade, is there any plan to study about Seamonkey on MS Win? Is there any plan to implement your enhancement which I want for Seamonkey on MS Win?
Please see Bug 459535 for Seamonkey 2 which was unfortunately closed as DUP of Bug 308076...

Comment 9

[WADA:World Anti-bad-Duping Agency]

For "respecting -P prof_name" on MS Win.

On MS Win, DDE is probably used for inter process communication. AFAIK, Fx/Sm on MS Win doesn't respond to DDE message(or doesn't open interface for DDE) if Fx/Sm is started with -no-remote switch. So I guess "respecting -P prof_name" on MS Win is very hard(I think relatively big design change is probably required around inter process communication).
I guess behavior of Fx/Sm on MS Win is same since initial replacement of "No -remote switch" by MOZ_NOREMOTE=1 & removal of "-remote switch" on MS Win. I guess it's the reason why bugs around switches relate to Profile Manager were WONTFIX'ed (e.g. Bug 459535). 
Kathleen Brade, thanks a lot for your answer and explanation.

Comment 10

[WADA:World Anti-bad-Duping Agency]

WONTFIX'ed Bug 441035 and Bug 441422 were for MS Win.
But WONTFIX'ed Bug 308076(and Bug 459535 which was closed as DUP of Bug 308076) was for Linux.
Bug 459638 for Linux was also closed as DUP of Bug 441422(for MS Win,WONTFIX) once, so I re-opened Bug 459638.
I think bugs for Linux(Bug 308076, Bug 459535, Bug 459638) were incorrectly closed as WONTFIX due to confusion of "spec/design on Linux" with "spec/design or current behaviour on MS Win". (I was also confused. I thought "behaviour on MS Win" was forced to "Fx/Sm on Linux Win" when MOZ_NO_REMOTE=1 was forced to "Fx/Sm on Linux Win".)

To Kathleen Brade: What do you think about these WONTFIX'ed bugs for Linux?

Comment 11

[Kathleen :Brade]

Benjamin Smedberg -- Can you weigh in on this bug?

The patch I posted solves this bug without disrupting existing code.  Is it opening up a security issue?  Are there other issues I should be aware of?

Comment 12

[Benjamin Smedberg]

I really do not want to support remoting in any form with multiple profiles.

Comment 13

[Mark Smith [:mcs]]

(In reply to comment #12)
> I really do not want to support remoting in any form with multiple profiles.

Why not?  Although the average user does not need more than one profile, advanced users routinely use them.  Fixing this bug so that remoting works better on Linux and similar OSes seems like an easy thing to do that will benefit quite a few people (people are using remoting with multiple profiles today and have to work around various toolkit limitations to do so).

Comment 14

[Benjamin Smedberg]

Because nsAppRunner is already fiendishly complex: the code here will only fix a small aspect of the problem, and introduces code paths that I don't want anyone hacking this file to have to think about.

Comment 16

[Jayson King]

(In reply to comment #3)
> Created an attachment (id=376975) [details]
> Proposed patch
> 
> With this patch, I can now open two copies of Firefox (using profiles 1 and 2)
> by doing the following:
> firefox -P 1 &
> firefox -P 2 &
> 
> And then I can open the mozilla.org page in the Firefox process that is using
> profile 1 and the mozilla.com page in the other process with these commands:
> firefox -P 1 http://mozilla.org/
> firefox -P 2 http://mozilla.com/
> 
> Does this patch open up any security issues?

 Kathleen Brade,

I attempted to use this patch with SeaMonkey 2.0.6pre (b1b05fd77e73) but unfortunately it did not work completely. Running seamonkey -P "profile" does indeed lead to a window opening with the correct profile, although if the profile is already running, the URL is not opened but instead a blank window is opened in that profile. If the profile is not already running, then the URL is opened correctly.

For the last year or so I have been using this script which I mentioned in bug 459535, which has been working:

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

With or without your patch, it is still necessary to first ping for a running SeaMonkey instance, and then either start the instance or send a remote command depending on the result. This isn't really ideal since it is racy and involves multiple launches of seamonkey, but for my purposes, it works. I do not use Firefox so I can't say whether your patch still works there or not.

Comment 17

[Jayson King]

(In reply to comment #16)
> 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

(replying to myself...)

The extra quotes around $@ are an error, since the openurl(...) already has quotes around it. The version of the script I'm actually using doesn't have those extra quotes.

This script has a limitation. The "openurl(...)" case does not work when "$@" contains spaces. That hasn't bothered me yet enough to fix it.