1367743 - About:profiles "launch profile in new browser" doesn't work

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, enhancement, P5)

Description

[Jim Mathies [:jimm]]

All this button does is open a new window within the currently running browser / profile combo. We should hide this button until the feature works. Tested on Windows w/Nightly 55.

Comment 1

[:Gijs (he/him)]

This is basically dead code until such time as someone decides to revive it, given bug 1239848, to which all issues with the existing implementation have so far been duped.

Comment 2

[Danial Horton]

Um, please DON'T hide it.

The button does actually work so long as you are clicking them from a no-remote started instance.

Comment 3

[Andrea Marchesini [:baku]]

Actually it works exactly how it should. It opens the selected profile in a new instance.
We should not remove about:profiles and if there are issues, we can simply fix them.

Comment 4

[Jim Mathies [:jimm]]

(In reply to Andrea Marchesini [:baku] from comment #3)
> Actually it works exactly how it should. It opens the selected profile in a
> new instance.
> We should not remove about:profiles and if there are issues, we can simply
> fix them.

Not on Windows, it just opens a new window int he same instance, using the currently open profile.

Comment 6

[Steven S.]

Jim, as mentioned in comment #2, if you add -no-remote to your Firefox shortcut, the Launch profile in new browser button works as expected.

This is not all that surprising, you cannot manually open another profile (with the -p "profilename") option without -no-remote either because Firefox is already running.

Perhaps there should be a check with a pop up message.

Comment 7

[jscher2000]

Can the code be revised to always use -no-remote (express or implied) on new instances? For example, I start Firefox normally in my default profile. I then use a desktop shortcut to start Firefox -P "profile2" -no-remote. In about:profiles in the "profile2" instance, I can launch "profile3" with no conflict (-no-remote doesn't appear on the command line but is somehow inherited?). Then in about:profiles in the "profile3" instance, I can launch "profile4" with no conflict (-no-remote doesn't appear on the command line). Since all four profiles operate independently at that point, I think it should be possible to achieve this effect from the original instance. Somehow. ;-)

Comment 8

[Ton [:Tonnes]]

From a Sumo perspective, I think it’s safe to say about:profiles comes in handy and we need this feature/button to work in any version without mentioning any tricks or bugs. Adding -no-remote would be required to make this work in FF release allright, but appears to break recognition of the default browser (or rather: profile) for links clicked in Thunderbird emails even when FF is already open and running the default profile.

See https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles/discuss/7232.

Comment 9

[David]

I didn't hit this bug in FF 57, but immediately hit it after upgrading to FF 58.

Comment 11

[LorenAmelang]

I just wasted an hour on this, in Windows 10, 59.0.3 (64-bit). I created a new Firefox profile. Left my real one as default, and clicked "Launch profile in new browser" under the new one. It looked just like my real one...  It was my real one! Turns out "Launch profile in new browser" always launches another instance of the currently running profile, regardless of which one is set as default or which profile's button you click!  To switch profiles you must set your chosen profile to default and completely close and restart Firefox! 

I can understand if you don't want to bother fixing it, I'd never seen it before in 13 years of using Firefox. But _please_ don't leave the unfixed button visible! It doesn't begin to do what it appears it should! 

BTW, my whole struggle with profiles today was pointless. LastPass support told me I could install their add-on in a test profile without risking my default profile. But their "Binary Component" installs simultaneously into all profiles. Glad I did a total backup first! Is that normal that an install in one profile affects all of them?

Comment 12

[Maja Frydrychowicz :impossibus (was :maja_zf) (needinfo me)]

I started seeing this on Windows 10 a while ago: "Launch profile in new browser" opens new window with same profile. I can reproduce with today's Nightly (62, buildid 20180523100147) as well as in a Dev Edition (61, buildid 20180510160705). Meanwhile, it works fine on 61 and 62 in mac os.

Comment 13

[Ton [:Tonnes]]

As reported, this issue only seems to affect Windows, regardless of release or Dev version. Adding -no-remote to the Firefox startup shortcut could help but may break recognition of the default browser.

Perhaps hiding the button for Windows only would be an option. Thinking of that and dead code, wouldn’t it be possible to adapt the button code to include -no-remote for Windows only?

Comment 14

[Danial Horton]

(In reply to Ton [:Tonnes] from comment #13)

> Perhaps hiding the button for Windows only would be an option.

Please don't.

The option works to sideload profiles without getting local profile data getting mixed in with roaming profile.

Comment 15

[LorenAmelang]

Okay, I get this is complicated in Windows. And there are partisans on all sides. How about adding some text above each "Launch profile in new browser" button:

"Warning: If you are using Windows, this button can only open a new instance of the profile that is already running! (Unless you have added -no-remote to your startup shortcut...  See [some simpler presentation than <https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles/discuss/7232> of why normal users probably don't want to do that] for more information.)"

Seems that would protect everyone's interests. Except those who want things to appear deceptively simple...

Comment 16

[Ted Campbell [:tcampbell]]

Attachment: 0001-Bug-1367743-Use-no-remote-flag-when-starting-new-bro.patch

Can we simply add "-no-remote" when launching process? This solves the problem on Windows for me.

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5512e36358b8e9edb9f979d59036e6fc38785ed0

Comment 17

[Graham Perrin]

Microsoft Windows only, yes? 

I don't have the bug on FreeBSD-CURRENT, and I haven't noticed it on Linux or Mac OS X. 

$ firefox --version ; pkg info firefox | grep Version
Mozilla Firefox 61.0
Version        : 61.0_3,1
$ date ; uname -v
Tue 10 Jul 2018 19:04:06 BST
FreeBSD 12.0-CURRENT #7 r336136: Tue Jul 10 03:01:24 BST 2018     root@momh167-gjp4-hpelitebook8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC

Comment 18

[Ted Campbell [:tcampbell]]

Yes, my patch only applies to Windows and I think that is the only platform affected by the -no-remote stuff.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/363749305334
Use no-remote flag when starting new browser from about:profiles. r=baku

Comment 20

[Jim Mathies [:jimm]]

Thanks!

Comment 21

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/363749305334