251134 - No way to open a new window in existing process by specifying a profile

Status: RESOLVED EXPIRED

(Toolkit :: Startup and Profile System, defect)

Description

[Raul Acevedo]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040706 Galeon/1.3.16
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040706 Galeon/1.3.16

Due to bug 20573, I'm trying to run Firefox using two different profiles, each
with different default window size characteristics: one for API docs, another
for standard browsing.

I use the default profile for standard browsing, and would like to have
"firefox" or "firefox -P default" be the action to my Firefox button and my URL
handler.  It should always use the default profile; the second profile I've
created, say OtherProfile, is for a very specific browser window that I want at
a certain size.

I cannot make this work.

1.  If I do: "firefox" then "firefox -P default", the second instance comes up
with the Profile Manager and doesn't let me pick the default profile because it
says it's already in use.

2.  I can't have my URL handler just be "firefox", because if I do "firefox",
then "firefox -P OtherProfile", then "firefox", the third instance will use the
last profile --- OtherProfile --- not the default profile.

3.  I thought I could use mozilla-xremote-client to detect if an instance is
running using the given profile, and then tell that instance for that profile to
open a new window, but mozilla-xremote-client ignores its -p argument.

At the very least, there is a bug in mozilla-xremote-client that it should use
the -p profile in checking what instance is running.  I would argue there is
also another bug in that firefox -P default should not bring up the Profile
Manager when there is another instance with default profile running.

IN SUMMARY: I would love it if either or both of these bugs were fixed, or if
someone could show me how to make Firefox do what I want, which is: open a new
window with the given profile, using an existing instance that is using that
profile if it exists.

Or if someone fixed bug 20573, that would be even better.   :)   Then I wouldn't
need two profiles, I could just have my windows open how I want them to open.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Raul Acevedo]

There are more comments about this at the end of the comments for bug 177996,
starting with #119.

Comment 2

[Iain MacDonnell]

I think at least part of the problem here is that the X property atom that's
supposed to contain the current profile is not getting set. Its name is
"_MOZILLA_PROFILE", but my current firefox window shows only:

% xprop | grep MOZILLA
_MOZILLA_PROGRAM(STRING) = "firefox"
_MOZILLA_USER(STRING) = "myusername"
_MOZILLA_VERSION(STRING) = "5.0"
%

I've tracked this back as far as XRemoteService::GetProfileName(). I wonder
if some of the recent profile-management changes have broken this. I've run
out of time for now, but will dig in more later, if noone else beats me to it :)

Comment 3

[Raul Acevedo]

I'd love to experiment with this, but I can't figure out how to set a property
with xset:

# xprop -set _MOZILLA_PROFILE default
xprop: error: unsupported conversion for _MOZILLA_PROFILE

Comment 4

[Iain MacDonnell]

(In reply to comment #3)
> I'd love to experiment with this, but I can't figure out how to set a property
> with xset:
> 
> # xprop -set _MOZILLA_PROFILE default
> xprop: error: unsupported conversion for _MOZILLA_PROFILE

You can set it with:

xprop -f _MOZILLA_PROFILE 8s -set _MOZILLA_PROFILE "default"

This actually allows 'mozilla-xremote-client -p default' to work ... provided
*all* open windows have that property set, but the firefox script would still
need some work to make use of that - it doesn't look for profile specification
at all... I'm hacking it a bit, inbetween real work :/

Comment 5

[Iain MacDonnell]

Attachment: firefox script horribly kludged to pass profile to xremote client - PoC only

Here's a really horribly hacked version of the firefox script that should pass
the profile (specified with '-P') to mozilla-xremote-client, and therefore
should utilise a window using that profile - this'll only work if ALL open
firefox windows have the profile property atom set.

This is not a proposed fix ... just a proof-of-concept. Let me know if it does
what you expect, and we'll see where we can go from there....

Comment 6

[Raul Acevedo]

(In reply to comment #5)

> This is not a proposed fix ... just a proof-of-concept. Let me know if it does
> what you expect, and we'll see where we can go from there....

It worked!  Not all windows need the profile atom... just the one where you want
the URL to show up.  In my case, even that doesn't matter because I use openurl
with new-window, so as long as one window has that atom.

I guess the trick is to get the Firefox source code to set that atom...
shouldn't be hard, right?  Modifying the scripts to pass the profile along
cleanly and have mozilla-xremote-client do the right thing shouldn't be that hard.

Comment 7

[Iain MacDonnell]

(In reply to comment #6)
> (In reply to comment #5)
> 
> > This is not a proposed fix ... just a proof-of-concept. Let me know if it does
> > what you expect, and we'll see where we can go from there....
> 
> It worked!  Not all windows need the profile atom... just the one where you want
> the URL to show up.  In my case, even that doesn't matter because I use openurl
> with new-window, so as long as one window has that atom.

It won't work consistently - if there are windows without the property set,
those could be used - it just depends on the order that the X server supplies
the list of windows in. I guess you got lucky so-far...


> I guess the trick is to get the Firefox source code to set that atom...
> shouldn't be hard, right?  Modifying the scripts to pass the profile along
> cleanly and have mozilla-xremote-client do the right thing shouldn't be that hard.

I think it's feasible. Interestingly, trunk mozilla (1.8a2) does set the
profile property atom correctly, so this can probably be considered a
regression, and is most likely fall-out from the new semi-single profile
enhancements. I think I'll spin off a new bug for it.

Comment 8

[Raul Acevedo]

(In reply to comment #7)

> > I guess the trick is to get the Firefox source code to set that atom...
> > shouldn't be hard, right?  Modifying the scripts to pass the profile along
> > cleanly and have mozilla-xremote-client do the right thing shouldn't be that
hard.
> 
> I think it's feasible. Interestingly, trunk mozilla (1.8a2) does set the
> profile property atom correctly, so this can probably be considered a
> regression, and is most likely fall-out from the new semi-single profile
> enhancements. I think I'll spin off a new bug for it.

Sounds great.  Once that's in, I think modifying the startup script should be
easy... use the -P value to query if that profile has an instance, and if so,
use mozilla-xremote-client to open in that instance.  If no -P is given, I guess
it's an open question as to whether it should default to "default" or if another
instance is running, use that profile.

Comment 9

[Benjamin Smedberg]

It is possible to run firefox without a named profile at all (using the -profile
flag). We are trying to hide the multiple-profiles stuff as an advanced feature
that is mainly for developers who need to test nightly builds or extensions.

Comment 10

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 11

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.