Closed Bug 308076 Opened 15 years ago Closed 15 years ago

Cannot have multiple profiles open (by launching from command line) any more on Linux without MOZ_NO_REMOTE

Categories

(Toolkit :: Startup and Profile System, enhancement)

x86
Linux
enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: ats-mozilla, Unassigned)

References

()

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050909 Firefox/1.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050909 Firefox/1.4

Prior to Deer Park, it used to be possible to invoke Firefox with "firefox
-ProfileManager" while it was already running to start a new instance with a
different profile. (I've got several profiles for different tasks -- a regular
one, a stripped-down one for talking to easily-confused network hardware that's
picky about proxies, another with special font/colour config for reading ebooks,
and so on.)

With Deer Park Beta 1, this doesn't work any more -- the profile manager options
are ignored if Firefox is already running, and you just get a new window from
the running instance. You have to invoke the new Firefox with the MOZ_NO_REMOTE
environment variable set in order to get the profile manager to come up, which
isn't obviously documented anywhere. It'd be nice if "firefox --help" would tell
you what you needed to do to get -P etc. to work in this case; maybe it could
have a -no-remote option or something, or automatically set MOZ_NO_REMOTE if
you're using any of the profile options.


Reproducible: Always

Steps to Reproduce:
1. Start Firefox with "firefox".
2. Start Firefox again with "firefox -ProfileManager".


Actual Results:  
A second Firefox window opens with the first profile.

Expected Results:  
The Profile Manager dialog should open.

Bug 257083 is related: it's complaining that the profile options don't work on
Windows. However, that's an "it never worked" problem; in this case it used to
work quite happily, so the behaviour in 1.5b1 is a regression.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Cannot have multiple profiles open any more on Linux without MOZ_NO_REMOTE → Cannot have multiple profiles open (by launching from command line) any more on Linux without MOZ_NO_REMOTE
Version: unspecified → Trunk
I have never been able to run two profiles at the same time without at least one
of them starting with MOZ_NO_REMOTE=1 so it must be a linux-only thing.
Tried it another time, started a 1.0 version with a different profile with a
1.0.6 allready running but it just opens another window of the same version and
the same profile.
The change to automatically remote was done on purpose. I am happy to consider
this bug a RFE for disabling the auto-remote feature if you have specified
-profilemanager, but the current code flow makes that hard to do. It's certainly
not something I'm planning on writing the code for.
Severity: normal → enhancement
Yep, I'm happy with that as an RFE. It's probably not the most elegant way to do
it, but an easy approach would be to make the "firefox" wrapper script look for
the profile arguments and export MOZ_NO_REMOTE if it sees them.
Soory if this is not the same issue... concering Linux nightlies.

I recall I was able to run a Trunk Linux nightly and then if I wanted to try out
a newer tinderbox build to say confirm if the newer build had a bug fixed or
such without shutting down the first build, I could do so by starting the second
build with the -profilemanager and using another profile. 

The last time I was able to do this with nightly builds (Not including aviary
1.0.1) was when the first build was April.4 or earlier as I have not been able
to run a second nightly side by side with the prfilemanager if the first build
was April.5 or newer, including the recent branch/trunk nightlies.

So this change happenned between April.4 and April.5 ? ..at least for me on the
non-installer tarbals as I rather dislike the linux installer.

I jsut saw Bug 287641 after a quick check on checkins.

Another thing (I'll post it here before opening a new bug) :
If, let's say, v1.0.6 is running and the user starts v1.5b1, then currently the
v1.0.6 will open a new window. I think in most cases when this happens, the user
wanted v1.5b1 to run, not another v1.0.6 window. Can this be made ?
*** Bug 318556 has been marked as a duplicate of this bug. ***
*** Bug 319497 has been marked as a duplicate of this bug. ***
Not sure that this is the "right way" to go about fixing this, but it definately works well. It doesn't affect other Mozilla applications, such as Thunderbird, as far as I can tell.
I see three ways to resolve this problem, ranking from the best, in my
opinion, to the worst (although they all have their advantages and
disadvantages):

1. modify nsAppRunner.cpp to check for presence of "profile switching
options" before trying to send command line to remote instance, e.g.
using pseudo-patch:

-if (!PR_GetEnv("MOZ_NO_REMOTE")) {
+if (!PR_GetEnv("MOZ_NO_REMOTE") && !checkForSwitchProfileArgs()) {
    // Try to remote the entire command line.
    // If this fails, start up normally.
   if (RemoteCommandLine())
     return 0;
 }

2. modify nsBrowserContentHandler.js to abort on all unrecognized
options or only on profile-changing options:
 if (curarg.match(/^-/)) {
   Components.utils.reportError("Warning: unrecognized command line flag
" + curarg + "\n");
   // To emulate the pre-nsICommandLine behavior, we ignore
   // the argument after an unrecognized flag.
+  throw NS_ERROR_ABORT;
-  ++i;
 } else {

3. Unix-specific: modify firefox shell script (browser/app/Mozilla.in)
or run-Mozilla.sh to recognize profile options and set MOZ_NO_REMOTE:
    *)
      # Move the unrecognized argument to the end of the list.
      arg="$1"
      shift
      set -- "$@" "$arg"
      pass_arg_count=`expr $pass_arg_count + 1`
+      case "x$arg" in
+        x-P* | x-profile*)
+         MOZ_NO_REMOTE=1
+         export MOZ_NO_REMOTE
+         ;;
+      esac
      ;;

The actual code will be more complex to properly handle situations
like:
firefox -P default
firefox -P default
i.e. the same profile but '-P' option is explicitly used. This will be
most useful to those who define their own URL handlers and want to use
some specific profile for some specific cases, e.g. in thunderbird user.js:
user_pref("network.protocol-handler.app.ftp", "firefox -P
ftp_secured_profile");
Shell script fix is probably no 
I also would like to point out that this bug is practically the same problem as supposedly fixed bug 289383.
Additionally, this bug is not an enhancement as it is categorized now, it is a bug (with normal or "mild" severity).
*** Bug 319702 has been marked as a duplicate of this bug. ***
*** Bug 320131 has been marked as a duplicate of this bug. ***
> 1. modify nsAppRunner.cpp to check for presence of "profile switching
> options" before trying to send command line to remote instance, e.g.
> using pseudo-patch:

This by itself is insufficient. You have to annotate the xremote service profile information. Se bug 251244. The basic problem here is that since you can run the app with the -profile switch, not every "profile" has a name. (And we don't use the same profile abstraction that seamonkey did.)

> 2. modify nsBrowserContentHandler.js to abort on all unrecognized
> options or only on profile-changing options:

This is not a good idea. People pass all sorts of odd command-line options that we ignore, and sometimes the -P or -profilemanager flags can "leak" into nsBrowserContentHandler even in first-launch situations.

> 3. Unix-specific: modify firefox shell script (browser/app/Mozilla.in)
> or run-Mozilla.sh to recognize profile options and set MOZ_NO_REMOTE:

This is also a bad idea, since if you run twice:

firefox -P test http://www.foo.com/
firefox -P test http://www.foo.com/

It *should* remote.

Besides which, I'm trying to get rid of the shell script entirely.
*** Bug 320207 has been marked as a duplicate of this bug. ***
*** Bug 321827 has been marked as a duplicate of this bug. ***
*** Bug 324380 has been marked as a duplicate of this bug. ***
cf. Same bug for Windows: bug 99828
Huh, isn't bug 99828 referring to Mozilla Suite (mozilla.exe, see summary)

Instead, bug 287896 is the same for FF on Windows.

(In reply to comment #0)
> maybe it could have a -no-remote option or something

After Bug 280725(killed -remote switch in Linux and forced "-remote" mode, as done on Win in tha past), MOZ_NO_REMOTE=1 was introduced in Linux world by Bug 289383 as done in the past on MS Win, then logan has kindly implemend -no-remote switch by Bug 325509 (Fixed on 2006-02-08, set MOZ_NO_REMOTE=1 internaly when "-no-remote" is specified).

(In reply to comment #9)
> I see three ways to resolve this problem

It looks for me that next is simple and sufficient, because externaly same as current(3 mode of MOZ_NO_REMOTE=1, -no-remote switch, and "no -no-remote switch") 
 (1) Backout all MOZ_NO_REMOTE=1 related codes from both MS Win & Linux
 (2) Introduce "-NoRemote" switch, which corresponds to "No -remote switch"
     on previous FF version for Linux.
 (3) Revive -remote switch
 (4) Make -remote deafult when MS Win.
     (and ignore parameter of "-remote xxxx" when MS Win, if required, then )
     (internaly set appropriate "-remote yyyy" for defaulted "-remote" mode.)  
 (5) Make -remote default when Linux, if same default is to be used
     on both MS Win & Linux.
What do you think about "switch text handling only" way?

Biggest problems of above are :
 (1)  "-NoRemote" switch can be written after "Firefox.exe",
      even though developers of MS Win version of FF hate it.
 (2)  Users can specify "-remote" switch even when MS Win, 
      even though FF developers want to hide it from users.

By the way, "Profile Manager UI" is going to be removed from FF by Bug 214675, in which some comment posters say "remove dangerous 'Profile Manger'.
So all of you will fortunately become free from complicated discussion on "-ProfileManager" switch in near future :-)
running multiple profiles simultaneously is of tremendous value.  my usage case is one default profile, with 50 extensions for normal work; test profile; profile opened from other apps.  in the last case, i want the browser window to open lighting fast, no bloat; used for links from email and rss readers and other apps.

but to do this i must set MOZ_NO_REMOTE.  however, i then cannot send urls to open windows, get the 'already running' msg.

i hope the command switch/remote/profile issues above are rationalized, and in doing so, i can have multiple simultaneous profiles, and be able to configure opening a url in a specific profile.  ie firefox.exe -P 'profile' -url 'xxx'.
My usage of multiple profiles is similar to that of Mark <mjm@chelsea.net>.  I like to use a "normal" profile and a "bare" profile.  I constantly struggle with getting remote windows opening in the correct profile.
Is there any hope of getting multiple profiles working again with FF? Any of the 2.0 beta/alpha releases aim to get this properly working?? 

thanks,
Osho
The current behavior (with the -no-remote commandline flag) is by design.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
What "-no-remote" command line flag?  That's what we have been asking for.  Do you mean this switch is included in the next major release of Firefox?  Or is it only in the MSWin version?
*** Bug 340815 has been marked as a duplicate of this bug. ***
(In reply to comment #24)
> What "-no-remote" command line flag?  That's what we have been asking for.  Do
> you mean this switch is included in the next major release of Firefox?  Or is
> it only in the MSWin version?

The -no-remote switch is present in Firefox from 2.0a2, and so will be in Firefox & Thunderbird 2.0 when released later this year. It works on all platforms. (Bug 325509 added it).
will -profilemanager option impy -no-remote ?
I think that it should.
*** Bug 344856 has been marked as a duplicate of this bug. ***
*** Bug 348353 has been marked as a duplicate of this bug. ***
*** Bug 353916 has been marked as a duplicate of this bug. ***
Duplicate of this bug: 373301
Why is this bug marked as "RESOLVED WONTFIX"? Launching Mozilla Firefox with different profile or different version of Firefox itself looks like it doesnt work – Firefox starts with different profile or even different version of Firefox starts.
Duplicate of this bug: 412155
Duplicate of this bug: 421651
Product: Firefox → Toolkit
Duplicate of this bug: 459535
Documentation on the web and in the help text strongly implies that "firefox -profilemanager" will open up a profile manager.  If this is going to open up a browser window, document it as such and provide documentation for how to open up the profile manager.  The correct documentation should be provided in --help and in the mozilla magazine that discusses profile manager.  (google "firefox profile manager ubuntu").  "RESOLVED WONTFIX" implies "we don't care about the UI".  The UI is not working and needs fixing.  It should not take a web search and a drill down through one bug report into a second in order to figure out how to open up a profile manager.
You need to log in before you can comment on or make changes to this bug.