Closed Bug 1367743 Opened 3 years ago Closed 2 years ago

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

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
mozilla63
Tracking Status
firefox63 --- fixed

People

(Reporter: jimm, Assigned: tcampbell)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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.
Summary: About:profiles 'launch profile in new browser" doesn't work → About:profiles "launch profile in new browser" doesn't work
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.
Blocks: 1240022
Component: General → Startup and Profile System
Product: Firefox → Toolkit
Um, please DON'T hide it.

The button does actually work so long as you are clicking them from a no-remote started instance.
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.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
(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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Priority: -- → P5
Duplicate of this bug: 1365594
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.
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. ;-)
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.
I didn't hit this bug in FF 57, but immediately hit it after upgrading to FF 58.
Duplicate of this bug: 1409824
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?
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.
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?
(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.
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...
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
Attachment #8981969 - Flags: review?(amarchesini)
Attachment #8981969 - Flags: review?(amarchesini) → review+
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
Yes, my patch only applies to Windows and I think that is the only platform affected by the -no-remote stuff.
Assignee: nobody → tcampbell
Pushed by tcampbell@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/363749305334
Use no-remote flag when starting new browser from about:profiles. r=baku
Thanks!
https://hg.mozilla.org/mozilla-central/rev/363749305334
Status: REOPENED → RESOLVED
Closed: 3 years ago2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
You need to log in before you can comment on or make changes to this bug.