486172 - firefox -P profile opens the wrong profile when running multiple profiles

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[pablo]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.8) Gecko/2009032711 Ubuntu/8.10 (intrepid) Firefox/3.0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.8) Gecko/2009032711 Ubuntu/8.10 (intrepid) Firefox/3.0.8

When running multiple profiles simultaneously firefox -P profile opens the wrong profile.

Reproducible: Always

Steps to Reproduce:
1. Open a profile: firefox -P profile1 -no-remote
2. Open another profile: firefox -P profile2 -no-remote
3. Open a window: firefox -P profile2
Actual Results:  
The first step opens the first window of profile1
The second step opens the first window of profile2
The third step opens a window of profile1

Expected Results:  
The first step opens the first window of profile1
The second step opens the first window of profile2
The third step should have opened a window of profile2

Comment 1

[Benjamin Smedberg]

I'm a little surprised it opens anything, but the code complexity required means this really isn't worth fixing.

Comment 2

[Mike Hommey [:glandium]]

Interestingly, according to bz, this works as expected on mac, and doesn't on linux and windows. I don't know exactly how much of nsNativeAppSupportWin would need to change for that to work on windows, but on linux, it should only be a matter of a few lines.

Comment 3

[Mike Hommey [:glandium]]

Attachment: WIP

This is enough to make the usecase in comment 0 work. The second profile still needs to be started with MOZ_NO_REMOTE/-no-remote, though, but later calling it without does the right thing.

Note that -remote 'openurl(url)' already does the right thing wrt the -P option.

However, when using the --profile parameter, neither works.

Comment 4

[Benjamin Smedberg]

Really, I don't want to accept additional testing and code complexity for this feature, especially since we're removing core support for named profiles.

Comment 5

[Mike Hommey [:glandium]]

(In reply to comment #4)
> Really, I don't want to accept additional testing and code complexity for
> this feature, especially since we're removing core support for named
> profiles.

Does this mean running different profiles concurrently won't be possible anymore?

Comment 7

[nwf]

The patch here appears not to fix a bug with CheckArg, which I believe is requisite (I do not recall exactly why, tho').  Please see the otherwise remarkably similar https://bug643418.bugzilla.mozilla.org/attachment.cgi?id=719331

I continue to think that at least one of these bugs should be kept open, so I am REOPENing this one.  If it really is the view of upstream that these are not, in fact, bugs, then I again urge, as I did in https://bugzilla.mozilla.org/show_bug.cgi?id=643418#c4, that -p with a remote should raise a runtime error and not silently open a window in the wrong profile.

Comment 8

[Mike Hommey [:glandium]]

Let's face it, i'm not actively working on this.

Comment 10

[Mike Hommey [:glandium]]

Attachment: Don't ignore a -p command line argument when using the Xremote protocol

On X11, when running firefox -p foo http://mozilla.org, and a window for another
profile is already open, the -p argument is ignored and a new tab or window is
opened in the unrelated session.

Previously, the equivalent firefox -p foo -remote openurl(http://mozilla.org)
would see that there is no window for the profile foo, complain about it, and
abort. If a window for the profile foo was open, however, a new tab or windows
would open in that session.

Here, we modify the behaviour such that firefox -p foo http://mozilla.org never
ignores the -p argument, and does the sensible thing depending on the context:
- if a window is already open for the profile, use that session.
- otherwise, open a new window for that profile.

When no -p argument is given, the behaviour is unchanged.

As RemoteCommandLine, which first attempts to open a connection with an existing
firefox, falls through when there is no existing firefox, the -p argument must be
kept in the command line. It turns out CheckArg didn't handle the case properly,
so fix this as well.

The changes in RemoteCommandLine otherwise match what used to be in
HandleRemoteArgument before bug 1080319.

Benjamin, as mentioned by email, you WONTFIXed this bug four years ago under the premise that the profile manager would die, and it's still not quite dead. This bug has prevented better uses of the command line (replacing -remote with something better) for too long.

Comment 11

[Benjamin Smedberg]

Comment on attachment 8573084 [details] [diff] [review]
Don't ignore a -p command line argument when using the Xremote protocol

I still feel like this is going to be a can of worms with all kinds of edge cases which aren't correct. But I guess good-enough wins.

Comment 12

[Mike Hommey [:glandium]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f1902c4276e1

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/f1902c4276e1

Comment 14

[Igor]

I try to check fix on firefox 39.0a1 (2015-03-11).

1. start firefox.exe
2. start firefox.exe -p foo google.com

google is opened in additional tab inside first instance of firefox. Additional -new-tab inside second command line is changed nothing.

Comment 15

[Nuno Silva [:njsg]]

Is the option supposed to be -p (lowercase p) or -P (uppercase P)? The documentation I found so far has uppercase P, I can't find lowercase p documented anywhere.

Which version did the fix land in? 39?