Closed Bug 1907783 Opened 2 months ago Closed 2 months ago

Browsing data loss when using the new clear history dialog if Firefox is not closed gracefully

Categories

(Toolkit :: Data Sanitization, defect, P1)

Firefox 128
Desktop
All
defect

Tracking

()

VERIFIED FIXED
130 Branch
Tracking Status
firefox-esr115 --- unaffected
firefox-esr128 129+ verified
firefox128 + wontfix
firefox129 + verified
firefox130 + verified

People

(Reporter: kanapa1, Assigned: hsohaney)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Steps to reproduce:

  1. Run Firefox version 128 stable or newer.
  2. Make sure the privacy.sanitize.useOldClearHistoryDialog pref is set to "false", which is now the default.
  3. Browse the web and open a few web pages to populate your local browsing history, or go directly to step 4 if you already have any history entries in your current profile.
  4. Go to: Hamburger application menu → Settings → Privacy & Security (or directly to about:preferences#privacy), then enable the "Clear history when Firefox closes" option and configure it so that anything except browsing history is cleared for obvious reasons, let’s say temporary cached files and pages.
  5. Forcefully close Firefox by issuing the following commands in a terminal: taskkill /f /im firefox.exe on Windows or kill -SIGKILL $(ps -x | grep firefox | awk '{print $1}') on Linux or in any other way that allows you to forcefully close a running application.
  6. Normally launch Firefox again as if nothing had happened.
  7. See what is described in the "Actual results" section.

Actual results:

During the very first launch after the forced shutdown, Firefox completely wipes out the entire browsing and download history, form data, site settings, cache, and cookies in the current profile, thereby causing permanent loss of user data with no built-in method to bring it back (or at least not until the profile backup is shipped later this year, which :mconley is actively working on).

Expected results:

After a forced shutdown of Firefox due to a freeze, BSOD/kernel panic, or an unexpected power loss, which are not pleasant experiences in themselves, Firefox should not further harm and intentionally get rid of user data without the user's consent.

Additional information:

One thing I noticed when comparing the new implementation in version 128 with the old one in 127, and without delving into the source code, is that every time Firefox is launched, it fills the privacy.sanitize.pending pref array with a few objects. One of them always contains the following array as one of its members: "itemsToClear": ["cache", "cookies", "history", "formdata", "downloads", "sessions"], which was not the case in version 127, where the content of the array was dynamic and depended on the user's settings on what they wanted to be cleared during a shutdown.

During a shutdown, however, the new implementation seems to use some other preferences to determine what data the user wants cleared. It then resets that array to the default value [] as the old implementation did.

This comes down to the key thing. That empty array prevents the browsing history and other data from being cleared during the next startup. However, forcibly closing Firefox prevents it from resetting that array to the default value [] during the shutdown, so the next time Firefox is launched, the contents of that array (i.e. cache, cookies, history, form data, downloads, and sessions) are read, and all user data is wiped out.

Regression range:

With the privacy.sanitize.useOldClearHistoryDialog pref forced to false, Mozregression points to bug 1856417 and bug 1861450 as the culprits (otherwise, bug 1896949 is shown, which is the one that let the new clear history dialog ride the trains to the release channel). Here's the relevant pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8b80895bf4a3bd55d159062a8741c771555285dd&tochange=244e6e5092d8ec91690845b38264d332b87983c4

Keywords: regression
Regressed by: 1896949

:hsohaney, since you are the author of the regressor, bug 1896949, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Flags: needinfo?(hsohaney)

IIRC on ungraceful exits, there is a sanitize on startup fallback which I think pbz and hannah implemented

Flags: needinfo?(pbz)

Sanitizer.sys.mjs indeed retries the clear on startup if it failed on shutdown, and to do that it uses the pending pref to extract the last pending sanitization.
It looks like this was not handled correctly, indeed multiple code points still use PREF_SHUTDOWN_BRANCH, but the new dialog moved to a different pref branch:
https://searchfox.org/mozilla-central/rev/54a5c4f14f3eb514a29e0cebcb5a095144bcd450/browser/modules/Sanitizer.sys.mjs#178,185,346,352,363

Flags: needinfo?(pbz)
Assignee: nobody → hsohaney
Severity: -- → S2
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P1

Working on this now! Thanks for finding this

Flags: needinfo?(hsohaney)
Pushed by pzuhlcke@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5c6bb39247ff
Use the new clear on shutdown branch to prevent losing pending shutdown items on unexpected shutdown. r=pbz,places-reviewers,Standard8
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 130 Branch

The patch landed in nightly and beta is affected.
:hsohaney, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox129 to wontfix.

For more information, please visit BugBot documentation.

Flags: needinfo?(hsohaney)

This is going to need some bake time before it ships to users due to the dataloss risk, so it's not a good candidate for a 128 dot release. Let's aim to have this fix ship in Fx129.

I can confirm that the latest Nightly with this patch included seems to work properly again, just like Firefox 127.

In my opinion as a user, uplifting this patch to the release channel will not result in any greater risk of browsing data loss than is currently the case with Firefox version 128.0. At present, for example, an unexpected power loss will wipe out your entire browsing history and more (which happened to me several times already) unless you know in advance what is going to happen and prepare for it beforehand by modifying a few prefs in about:config.

But I may be wrong, so perhaps someone familiar with this part of the Firefox codebase could comment on this.

Thanks for confirming!

A release uplift is risky per-se so it has to be weighted against the severity of the bug being addressed. While it's a dataloss bug and it's really annoying to loose all that data it's still an edge case. If we uplift code to release we risk introducing new regressions. That's why we've decided to fix it in the upcoming release instead and get some more testing time in Nightly and Beta.

Comment on attachment 9412868 [details]
Bug 1907783 - Use the new clear on shutdown branch to prevent losing pending shutdown items on unexpected shutdown. r?pbz

Beta/Release Uplift Approval Request

  • User impact if declined: Potential dataloss on unexpected shutdown of Firefox. This affects users who have clearing on shutdown enabled.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: See comment 0
  • List of other uplifts needed: None
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): It's a small code change, but since it's updating how clearing on shutdown is handled there is risk of further dataloss if we overlooked something.
    The change has automated test coverage though and has been in Nightly for a couple days and we haven't observed any issues.
  • String changes made/needed:
  • Is Android affected?: No

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Dataloss bug
  • User impact if declined: Potential dataloss on unexpected shutdown of Firefox. This affects users who have clearing on shutdown enabled.
  • Fix Landed on Version:
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): It's a small code change, but since it's updating how clearing on shutdown is handled there is risk of further dataloss if we overlooked something.
    The change has automated test coverage though and has been in Nightly for a couple days and we haven't observed any issues.
Attachment #9412868 - Flags: approval-mozilla-esr128?
Attachment #9412868 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9412868 [details]
Bug 1907783 - Use the new clear on shutdown branch to prevent losing pending shutdown items on unexpected shutdown. r?pbz

Approved for 129.0b8

Attachment #9412868 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Comment on attachment 9412868 [details]
Bug 1907783 - Use the new clear on shutdown branch to prevent losing pending shutdown items on unexpected shutdown. r?pbz

Approved for 128.1esr.

Attachment #9412868 - Flags: approval-mozilla-esr128? → approval-mozilla-esr128+

Uplifted to 128.1esr and 129.0b8 by pbz

Flags: needinfo?(hsohaney)
QA Whiteboard: [qa-triaged]

I can reproduce the issue in Release v128.0.8 and Nightly v130.0a1 from 2024-07-10, while it does not reproduce in ESR v115.13.0esr; The history is cleared on an unexpected shutdown of Firefox when clearing on shutdown is enabled.
This issue no longer reproduces in Nightly v130.0a1 from 2024-07-24, Beta v129.0b8 while it still reproduces in the latest ESR v128.0esr. It will be verified in ESR v128.1esr when it is available.
Testing was performed on Windows 10, MacOS 11 and Ubuntu 22. Thank you.

OS: Unspecified → All
Hardware: Unspecified → Desktop

I can reproduce this issue in ESR v128.0esr and I can confirm the fix in ESR v128.1.0esr. The testing was performed on Windows 10 and MacOS 11.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: