1931982 - The checked profile selector dialog checkbox prevents launching any profile

Status: VERIFIED FIXED

(Toolkit :: Startup and Profile System, defect, P2)

Description

[❌ PTO, back 8/18 ❌ Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

1. Enable profiles by setting browser.profiles.enabled pref to true
2. Create several profiles
3. Click on "Profiles" then "Manage Profiles", launching the profile selector dialog
4. In the profile selector dialog, check the "Show at startup" checkbox in the profile
5. Close all open profiles and restart Firefox
6. The profile selector dialog will display, with the "Show at startup" checkbox checked"
7. Click the profile card to launch any of the profiles in the profile group

Expected behavior: the profile selector dialog is dismissed and the selected profile launches

Actual behavior: the profile selector dialog is dismissed, then reappears. Firefox only starts into a profile if the "Show at Startup" checkbox is unchecked before clicking on a profile (and in that case the wrong profile is launched, see bug 1931984).

We should be ignoring the "show at startup" checkbox state (that is, the ShowSelector state in profiles.ini) if the user is trying to launch a profile from the profile selector window.

Comment 2

[Dave Townsend [:mossop] (PTO until Aug 21st)]

Attachment: Bug 1931982: Fix the startup profile UI to correctly signal back to nsAppRunner what profile needs to launch. r=jhirsch!

When displaying the profile selector on startup we cannot use the normal method of launching a
selected profile by simply launching an new instance of Firefox. This would lose all state from
the original process including any passed command line arguments. Instead we must signal back to
nsAppRunner what profile it should launch. We also need to properly shut down the sqlite database
before shutdown begins as our normal hook isn't in place and the process crashes if the database
hasn't been shut down correctly.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e4a8608d96d5
Fix the startup profile UI to correctly signal back to nsAppRunner what profile needs to launch. r=jhirsch

Comment 4

[Atila Butkovits]

Backed out for causing failures at test_first_startup.py.

Backout link: https://hg.mozilla.org/integration/autoland/rev/21cc72f3e68b260d34494be2bfa50f38e1c08ae4

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception&revision=e4a8608d96d59ed66f2ceed194d83fda57179b2c&selectedTaskRun=Mroum-WCSkaR4ZL_6YUMig.0

Failure logs:
https://treeherder.mozilla.org/logviewer?job_id=484227742&repo=autoland&lineNumber=31509
https://treeherder.mozilla.org/logviewer?job_id=484227678&repo=autoland&lineNumber=2510

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/32c217dc0c44
Fix the startup profile UI to correctly signal back to nsAppRunner what profile needs to launch. r=jhirsch

Comment 6

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/32c217dc0c44

Comment 7

[Simona Badau, Desktop QA]

Removing the qe-verify+ flag as the Profile Switching feature was not released in Firefox 135, and the Profile Selector is still a work in progress.

Comment 8

[Simona Badau, Desktop QA]

Reproduced the initial issue on Nightly 134.0a1 (Build ID: 20241119094105).

Verified as fixed on the latest Nightly 137.0a1 - a new profile can be opened from the Profile selector window when the "Choose a profile when Nightly opens" is checked.