289383 - X-Remote doesn't differentiate between profiles anymore

Status: RESOLVED FIXED

(Core Graveyard :: X-remote, defect)

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

This is a regression in the past few days, and it makes it much harder for me to
test my changes while using the trunk as my primary browser, so marking as blocker.

X-Remote no longer differentiates between profiles.  It used to not use X-Remote
when the active window was running a different profile from the one requested.

Steps to reproduce:
 1. Create two profiles, (say, "default" and "counters").
 2. ./firefox -P default
 3. ./firefox -P counters

Expected results:
 2. browser window in default profile appears
 3. browser window in counters profile appears

Actual results:
 2. browser window in default profile appears
 3. browser window in default profile appears

Comment 1

[Darin Fisher]

I'm surprised to see this bug filed as a regression.  I thought this never
worked since the advent of the new toolkit profile stuff (back before firefox
1.0).... see bug 251244.  I believe you... I'm just really confused ;-)

Comment 2

[Benjamin Smedberg]

Here's what's happening: previously, xremote would set the "profile" flag if -P
were present on the command line

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/xre/nsAppRunner.cpp&rev=1.77&cvsroot=/cvsroot&mark=888-892#878

However, this has two problems:

1) it's inconsistent: if you don't specify a profile and use the default, or if
you use the profile manager, we don't set the profile atom. This is a result of
the "profiles are a path, not a name" design choice. roc said he had a fix
floating around, but I probably bitrotted it pretty badly with this patch anyway.

2) If I were to add this code back, I can't use the "CheckArg" function, or I
would have to add additional params: if xremote fails, we now do a regular
launch; CheckArg removes params from the argument list, which means that
"SelectProfile" wouldn't see it later on.

I really meant to add a MOZ_NO_REMOTE env checker for the automatic xremoting,
just like we do for the win32 remoting. I can do that here.

Comment 3

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Ah, yeah, the script I use to start firefox always passes a -P <profilename> on
the commandline, so this has always worked for me.  (The whole script is really
legacy from before this code existed, but it doesn't hurt anything, and
apparently helped with getting the profile atom right.)

Comment 4

[Benjamin Smedberg]

Attachment: Add MOZ_NO_REMOTE check

Comment 5

[Johnny Stenback (:jst)]

Comment on attachment 179957 [details] [diff] [review]
Add MOZ_NO_REMOTE check

sr=jst

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Comment on attachment 179957 [details] [diff] [review]
Add MOZ_NO_REMOTE check

r=dbaron, although I'm not sure why you're removing the help text

Comment 7

[Benjamin Smedberg]

Attachment 179957 [details] [diff] checked in on trunk. I'm going to mark this FIXED; there is
already a bug open about always passing a profile name to xremote even if the -P
flag is not used.

Comment 8

[Benjamin Smedberg]

*** Bug 300791 has been marked as a duplicate of this bug. ***

Comment 9

[David Crick]

running dp a2:

   firefox &
   firefox -P second &

Warning: unrecognized command line flag -P

and am thus unable to simulataneously run two profiles.

Is this (still) part of this bug, or is there another one specific to this problem?

Comment 10

[David Crick]

(ignore my comment #9 - setting MOZ_NO_REMOTE=1 fixes it)

Comment 11

[Benjamin Smedberg]

*** Bug 292237 has been marked as a duplicate of this bug. ***

Comment 12

[Benjamin Smedberg]

*** Bug 303138 has been marked as a duplicate of this bug. ***