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

RESOLVED FIXED in Firefox 39

Status

()

defect
RESOLVED FIXED
10 years ago
3 years ago

People

(Reporter: pablo, Assigned: glandium)

Tracking

unspecified
mozilla39
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox39 fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

10 years ago
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
Component: Shell Integration → Startup and Profile System
Product: Firefox → Toolkit
QA Contact: shell.integration → startup

Comment 1

10 years ago
I'm a little surprised it opens anything, but the code complexity required means this really isn't worth fixing.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
(Assignee)

Comment 2

8 years ago
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.
(Assignee)

Comment 3

8 years ago
Posted patch WIP (obsolete) — Splinter Review
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.
Assignee: nobody → mh+mozilla
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---

Comment 4

8 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago8 years ago
Resolution: --- → WONTFIX
(Assignee)

Comment 5

8 years ago
(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?
Status: RESOLVED → VERIFIED
Resolution: WONTFIX → FIXED
(Assignee)

Updated

8 years ago
Status: VERIFIED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: FIXED → WONTFIX
(Assignee)

Updated

6 years ago
Duplicate of this bug: 643418

Comment 7

6 years ago
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(Assignee)

Comment 8

6 years ago
Let's face it, i'm not actively working on this.
Assignee: mh+mozilla → nobody
(Assignee)

Updated

4 years ago
Duplicate of this bug: 1138053
(Assignee)

Comment 10

4 years ago
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.
Assignee: nobody → mh+mozilla
Attachment #541624 - Attachment is obsolete: true
Attachment #8573084 - Flags: review?(benjamin)
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.
Attachment #8573084 - Flags: review?(benjamin) → review+
https://hg.mozilla.org/mozilla-central/rev/f1902c4276e1
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39

Comment 14

4 years ago
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.
(Assignee)

Updated

4 years ago
Blocks: 1142733

Updated

4 years ago
Depends on: 1182395

Comment 15

3 years ago
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?
You need to log in before you can comment on or make changes to this bug.