firefox -P [someProfile] [someURL] doesn't open in desired profile, when multiple profiles are active.

RESOLVED DUPLICATE of bug 486172

Status

()

RESOLVED DUPLICATE of bug 486172
8 years ago
5 years ago

People

(Reporter: linuxadmin, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (X11; Linux i686 on x86_64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:2.0) Gecko/20100101 Firefox/4.0

Scenario 1:
  No profiles are running.
  firefox -P [someProfile] [someURL] DOES open the URL in desired profile.
  OK.

Scenario 2:
  Several profiles are running (one of them is the desired to open the URL).
  firefox -P [someProfile] [someURL] opens the URL in (randomly) ONE of the running profile.
  NOT OK.


Reproducible: Always

Steps to Reproduce:
1. open multiple profiles using "firefox -P [PROFILE_NAME] -no-remote"
2. use "firefox -P [someProfile] [someURL]"
3. URL is opened in ANY of the running profiles (randomly, or perhaps in the last one active, or in the last one started, don't know for sure)

Comment 1

8 years ago
This does seem inconsistent - I was able to reproduce this, but it does work work occasionally. weird.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

6 years ago
Created attachment 719331 [details] [diff] [review]
Make RemoteCommandLine check for profile argument flag

I originally posted this as part of a patch for a different bug about argument handling, possibly erroneously, having missed this bug in the list (oops, sorry).  Anyway, here it is where hopefully more people will find it. :)

The changes to CheckArg are hopefully now sufficiently well-commented; the added call was tickling a bug there (the profile name was coming back as "-p" rather than the next argument).  From a quick look around the file, this is the only call that would have been impacted. (It is possible, as an aside, that the code under the heading "// Add the -override argument back (it is removed automatically be CheckArg) if there is one" could be eliminated by adjusting the call to CheckArg("override",...) earlier, but I did not make that change as I am unprepared to test it.)
Attachment #719331 - Flags: review?(benjamin)

Comment 3

6 years ago
This code is incredibly fragile, and supporting remoting with multiple profiles is not a feature that I think we should support in the current setup.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX

Updated

6 years ago
Attachment #719331 - Flags: review?(benjamin) → review-

Comment 4

5 years ago
I do not understand the assertion about the fragility of this code.  While that may be true, as it stands, the code is so very close to doing the right thing -- the patch attached above is minuscule!  If, however, this is not to be supported, please consider making passing -P with an active remote an error; the current behvior of opening a window in the wrong profile is completely wrong.

That said, however fragile this code may be, and however much this feature may not be a good idea "in the current setup", this bug should stay open for the future.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Component: General → Startup and Profile System
Product: Firefox → Toolkit
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 486172
You need to log in before you can comment on or make changes to this bug.