2063993 - Disable Rust Storage for release build

Status: VERIFIED FIXED

(Toolkit :: Password Manager, task)

Comment 1

[Johannes [:joschmidt]]

Attachment: Bug 2063993 - Disable Rust logins storage on release

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/bd5a8eb9c6d6
https://hg.mozilla.org/integration/autoland/rev/bd05ed2ef067
Disable Rust logins storage on release r=dimi

Comment 3

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Firefox 154 shipped the new Rust logins storage backend enabled on release. Since the release we have received reports that indicate the migration and the new backend regress core password manager behaviour for release users:

• Bug 2064411 — Primary Password prompt appears on every browser startup (Windows, 154).

• Bug 2064491 — Primary Password prompt appears on the first PDF opened per session; goes away with signon.rememberSignons=false (Windows, 154).

• Additional user reports on Reddit about degraded browsing/startup performance on 154.

Users with a Primary Password see an unexpected credential prompt on every session, which is both a confusing UX regression and a phishing-conditioning risk. There is no user-facing off switch.

This patch turns the backend off on release (and ESR) while keeping it enabled on Nightly and Beta, so we can keep testing and fix the root causes without exposing all release users. Urgency: 154 is live, so we would like this in the next 154 dot release, plus Beta so that 155 ships with it disabled.

• Code covered by automated testing?: yes
• Fix verified in Nightly?: no
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: Test 1: pref check (new profile)

1. Start the patched build with a new profile.
2. Open about:config and search for signon.storage.rust.enabled.

Expected: the value is false. Also check signon.storage.rust.active, it should be false too.

Note: on Beta builds signon.storage.rust.enabled is expected to stay true. The pref is only turned off for release and ESR.

Test 2: existing profile that already used the new backend

1. Start Firefox 154 (unpatched) with a new profile and open about:config. Wait until signon.storage.rust.active is true. Restart if it is still false.
2. Open about:logins, save a login for https://qa-test.example, and note the total number of logins.
3. Close Firefox, update to the patched build, and start it again with the same profile.
4. Open about:config and check signon.storage.rust.enabled and signon.storage.rust.active.
5. Open about:logins and check the list of logins.
6. Save a new login, edit it, delete it, and check that autofill works on a test login form.

Expected: both prefs are false. The logins that existed before step 1 are all present. The login saved in step 2 is no longer listed - this is expected and not a bug. Saving, editing, deleting and autofill work normally, and no error message or empty-list state appears.

• Risk associated with taking this patch: low
• Explanation of risk level: The patch is a two-line, build-time pref default change (signon.storage.rust.enabled) gated on MOZ_UPDATE_CHANNEL. No product code paths are added or modified; it selects the JSON logins backend that was the default up to and including Firefox 153, i.e. the well-tested pre-154 behaviour. Nightly and Beta are unchanged, so ongoing development and testing of the Rust backend continue.

One known consequence: for release profiles that already migrated on 154, signon.storage.rust.active remains set as a user pref, so with the new signon.storage.rust.enabled=false default the migrator takes its revert path once and switches the profile back to logins.json. Logins added or modified while the Rust backend was active are therefore not visible afterwards. logins.json still holds the complete pre-migration set, and the Rust database (logins.db) is left in the profile, but the two are not merged. Note that the Rust database is cleared if the backend is ever re-enabled, since the migration starts by wiping it and re-importing from logins.json. Given 154 has only been on release for a short time, we consider this exposure small compared to the ongoing Primary Password prompt regressions.

• String changes made/needed?: None
• Is Android affected?: no

Comment 4

[Johannes [:joschmidt]]

Attachment: Bug 2063993 - Disable Rust logins storage on release

Original Revision: https://phabricator.services.mozilla.com/D319038

Comment 5

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined/Reason for urgency: Firefox 154 shipped the new Rust logins storage backend enabled on release. Since the release we have received reports that indicate the migration and the new backend regress core password manager behaviour for release users:

• Bug 2064411 — Primary Password prompt appears on every browser startup (Windows, 154).

• Bug 2064491 — Primary Password prompt appears on the first PDF opened per session; goes away with signon.rememberSignons=false (Windows, 154).

• Additional user reports on Reddit about degraded browsing/startup performance on 154.

Users with a Primary Password see an unexpected credential prompt on every session, which is both a confusing UX regression and a phishing-conditioning risk. There is no user-facing off switch.

This patch turns the backend off on release (and ESR) while keeping it enabled on Nightly and Beta, so we can keep testing and fix the root causes without exposing all release users. Urgency: 154 is live, so we would like this in the next 154 dot release, plus Beta so that 155 ships with it disabled.

• Code covered by automated testing?: yes
• Fix verified in Nightly?: no
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: Test 1: pref check (new profile)

1. Start the patched build with a new profile.
2. Open about:config and search for signon.storage.rust.enabled.

Expected: the value is false. Also check signon.storage.rust.active, it should be false too.

Note: on Beta builds signon.storage.rust.enabled is expected to stay true. The pref is only turned off for release and ESR.

Test 2: existing profile that already used the new backend

1. Start Firefox 154 (unpatched) with a new profile and open about:config. Wait until signon.storage.rust.active is true. Restart if it is still false.
2. Open about:logins, save a login for https://qa-test.example, and note the total number of logins.
3. Close Firefox, update to the patched build, and start it again with the same profile.
4. Open about:config and check signon.storage.rust.enabled and signon.storage.rust.active.
5. Open about:logins and check the list of logins.
6. Save a new login, edit it, delete it, and check that autofill works on a test login form.

Expected: both prefs are false. The logins that existed before step 1 are all present. The login saved in step 2 is no longer listed - this is expected and not a bug. Saving, editing, deleting and autofill work normally, and no error message or empty-list state appears.

• Risk associated with taking this patch: low
• Explanation of risk level: The patch is a two-line, build-time pref default change (signon.storage.rust.enabled) gated on MOZ_UPDATE_CHANNEL. No product code paths are added or modified; it selects the JSON logins backend that was the default up to and including Firefox 153, i.e. the well-tested pre-154 behaviour. Nightly and Beta are unchanged, so ongoing development and testing of the Rust backend continue.

One known consequence: for release profiles that already migrated on 154, signon.storage.rust.active remains set as a user pref, so with the new signon.storage.rust.enabled=false default the migrator takes its revert path once and switches the profile back to logins.json. Logins added or modified while the Rust backend was active are therefore not visible afterwards. logins.json still holds the complete pre-migration set, and the Rust database (logins.db) is left in the profile, but the two are not merged. Note that the Rust database is cleared if the backend is ever re-enabled, since the migration starts by wiping it and re-importing from logins.json. Given 154 has only been on release for a short time, we consider this exposure small compared to the ongoing Primary Password prompt regressions.

• String changes made/needed?: None
• Is Android affected?: no

Comment 6

[Johannes [:joschmidt]]

Attachment: Bug 2063993 - Disable Rust logins storage on release

Original Revision: https://phabricator.services.mozilla.com/D319038

Comment 7

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/2b855ff6a276
https://hg.mozilla.org/releases/mozilla-release/rev/c16286f609cd

Comment 8

[Johannes [:joschmidt]]

Attachment: Bug 2063993 - restore logins after switching back to json

Comment 9

[Cosmin Sabou [:CosminS]]

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

Comment 10

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/b38d1226bf17
https://hg.mozilla.org/releases/mozilla-beta/rev/c481dd68f7ce

Comment 11

[Phabricator Automation]

Comment on attachment 9628417 [details]
Bug 2063993 - restore logins after switching back to json

Revision D319826 was moved to bug 2065593. Setting attachment 9628417 [details] to obsolete.

Comment 12

[Giorgia Nichita, Release Desktop QA]

Verified as fixed on Windows 11, Ubuntu 24.04, and macOS 15 using Firefox 154.0.1, Firefox 155.0b4, and Nightly 156.0a1.
We confirmed that signon.storage.rust.enabled is false by default on Firefox 154.0.1 and true on Beta 155 and Nightly 156, as expected. The signon.storage.rust.active pref also changed as expected when enabling/disabling the Rust storage backend and after updating to the patched version.
Following the STR for Bug 2065593, after disabling Rust storage and restarting Firefox, the newly created login and the modified password were retained.
This differs from the original STR for Bug 2063993, which states that the newly created login should no longer be listed. However, Bug 2065593 was added later to restore logins when switching back to JSON, so retaining the login is now the expected behavior.