1138053 - Can't use -p to select running Firefox instance for -new-tab etc.

Status: RESOLVED DUPLICATE of bug 486172

(Core Graveyard :: X-remote, defect)

Description

[Tom S [:evilpie]]

Bug 1080319 Comment 1080319
> Confirming that removing the -remote option breaks this use case.
> 
> I was using firefox profiles with the -remote option to synchronize with KDE
> activities (one profile per activity) and now I can't open new tabs /
> windows in the current activity anymore.
> 
> firefox -P $profilename -new-tab $url
> 
> just ignores the profile name and it opens the tab in the last opened profile
> 
> firefox -P $profilename -no-remote -new-tab $url
> 
> simply does not open anything, as it complains that firefox is already
> running.
> 
> Please provide a way to open new tabs in a specified profile from the
> command line!!
> 

I think this might be easy to fix if we actually pass the profile parameter

Comment 1

[Mike Hommey [:glandium]]

It's likely a dupe of bug 486172

Comment 2

[Tom S [:evilpie]]

Attachment: v1

You are probably right. I added some code that allows us find a "good" window, in case we don't find a window with that exact profile. Thus we should be backwards compatible with people specifying a non-existing profile.

Comment 3

[Tom S [:evilpie]]

I guess we shouldn't not actually remove the -p and -profile argument.

Comment 4

[Tom S [:evilpie]]

Attachment: v2 - Send command line to firefox process with selected profile

Comment 5

[Mike Hommey [:glandium]]

Comment on attachment 8570911 [details] [diff] [review]
v2 - Send command line to firefox process with selected profile

Review of attachment 8570911 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/xre/nsAppRunner.cpp
@@ +1651,5 @@
>      return REMOTE_ARG_BAD;
>    }
>  
> +  const char *profile = nullptr;
> +  ar = CheckArg("p", true, &profile, false);

the first bool should be false, like it used to be. The second, I'm not sure. What does it buy us to keep the argument in argv?

@@ +1653,5 @@
>  
> +  const char *profile = nullptr;
> +  ar = CheckArg("p", true, &profile, false);
> +  if (ar != ARG_FOUND)
> +    ar = CheckArg("profile", true, &profile, false);

-p and --profile don't give the same thing. The former is for a profile *name*, the latter for a profile *path*. We actually don't store a _MOZILLA_PROFILE when the original session was launched with a profile *path*.

::: widget/xremoteclient/XRemoteClient.cpp
@@ +523,5 @@
>          }
>      }
>  
> +    // At this point the window is usually good enough.
> +    goodWindow = w;

It seems to me this changes the behavior in a significant way. With this change, if you given -p and the profile doesn't match, the window is still considered a candidate.

That would means, with no previously running firefox, that the following sequence would only open one window, in the same profile:
  firefox -p foo
  firefox -p bar

Comment 6

[bartolinidb]

(In reply to Mike Hommey [:glandium] from comment #1)
> It's likely a dupe of bug 486172

Yes, it looks very much the same problem.
Has this really been broken since 2009?!

Unfortunately, I don't have a lot of spare time right now, I'll try to take a look at the code following the patch that Tom posted as soon as I find a minute.

Thank you guys for looking into this, having this feature working correctly would really help my workflow by letting me easily associate Firefox profiles with KDE activities and have my browsing sessions for different projects easily saved and restored.
KDE-based browsers like Konqueror or Rekonq actually provide this feature, but they're still quite buggy in many other ways, being able to use Firefox would be a great deal better..

Comment 7

[Mike Hommey [:glandium]]

(In reply to bartolinidb from comment #6)
> (In reply to Mike Hommey [:glandium] from comment #1)
> > It's likely a dupe of bug 486172
> 
> Yes, it looks very much the same problem.
> Has this really been broken since 2009?!

This has been broken forever.

Comment 8

[Tom S [:evilpie]]

>It seems to me this changes the behavior in a significant way. With this change, if you given -p and >the profile doesn't match, the window is still considered a candidate.
Wouldn't this already happen? We just ignore the profile right now and take the first matching app-name and user name instance.

Comment 9

[Pavlos Touboulidis]

From what I gather this was working fine on Linux until very recently.

There needs to be a way to target a specific profile when issuing commands, like opening URLs.

Comment 10

[Mike Hommey [:glandium]]

(In reply to Tom Schuster [:evilpie] from comment #8)
> >It seems to me this changes the behavior in a significant way. With this change, if you given -p and >the profile doesn't match, the window is still considered a candidate.
> Wouldn't this already happen? We just ignore the profile right now and take
> the first matching app-name and user name instance.

Sure, we do that with -new-tab, etc. And that's what you're trying to fix. But we didn't do that with -remote.

Comment 11

[Mike Hommey [:glandium]]

All things considered, this *is* a dupe of bug 486172, and the patch there should be all that's required, modulo the fact that it's old and needs to be refreshed, which is what part of the patch here is. I'll attach a refreshed patch there.