Open Bug 1427244 Opened 7 years ago Updated 2 years ago

Enforce privacy settings on next startup, when previous application close was due to a crash

Categories

(Firefox :: Session Restore, enhancement, P3)

57 Branch
enhancement

Tracking

()

People

(Reporter: soren.nissen+mozilla, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: dataloss, privacy, ux-consistency, Whiteboard: [good-next-bug])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36

Steps to reproduce:

Setup: 57.0.2 running under Windows 10 version 1709

Step 1: Go to about:preferences#privacy

Step 2: Under "History," ensure the following boxes are unchecked:
[]Always use private browsing mode
[]Remember my browsing and download history
[]Remember search and form history
[]Accept cookies from websites

Step 3: Ensure the following box is checked:
[x]Clear history when Firefox closes

Step 4: The checked box has a "Settings" button. Click it. This should open the dialog "Settings for Clearing History"

Step 5: Esure the following boxes are checked:
[x]Browsing & Download History
[x]Active Logins
[x]Form and Search History
[x]Cache
[x] Offline Webside Data

Step 6: Ensure the following boxes are unchecked:
[] Cookies
[] Site Preferences

Step 7: Save all history settings.

Step 8: Close all tabs except one tab.

Step 9: Direct that tab to any website that would should not normally be opened when you launch firefox.

Step 10: Crash Firefox. Under Windows 10, the following process works:

Step 10.1: Open the Task Manager.
Step 10.2: IF you are not already in advanced mode, press "More details" in the lower-left corner.
Step 10.3: Go to the "Details" pane
Step 10.4: Click the "Name" column to sort processes by name.
Step 10.5: Locate the Firefox process with the highest memory usage
Step 10.6: Right click that process and select "End Process Tree"
Step 10.7: A dialog should open. In the dialog, click the button labelled "End process tree"
Step 10.8: If this closed all the other Firefox processes you're done. Otherwise, repeat from step 10.5

Step 11: Launch Firefox

ADDITIONAL NOTES 1:
The outcome will depend on the order the Firefox processes were killed. Step 10 repros 5 out of 6 times for me, and I think the non-repro may have been a misclick.

ADDITIONAL NOTES 2:
I have also been able to repro this by doing things that don't crash firefox but close it in other unconventional ways, e.g. by changing a setting that calls for a restart of Firefox. On launch, it would continue the previous session (unexpected) instead of starting fresh (Expected)


Actual results:

On launching, Firefox will do one of three things A, B or C depending on how it was crashed.

A: It may start up as expected (This happened for me once)

B: It may start up with the page you were on loading in immediately without showing the "restore pages" dialog (This happened to me three times)

C: It may start up with the Restore Previous Session prompt open, displaying the page you were using in the text.

A is valid behavior. B and C are bugs.


Expected results:

Firefox should display the same startup behavior as if it had been closed normally.
I would say that this is not unexpected as clearing history and cache happens during the closing process of Firefox. And when Firefox crashes, this process does not happen, so the history is not deleted (as everything that should happen when Firefox is closed).

You're assuming that this process happens when Firefox is launched (the last part of your comment makes me believe that), but it is clearly stated in the preferences that it happens when Firefox closes ("normally" is implicit).
(In reply to Flore Allemandou [:flore] from comment #1)
>I would say that this is not unexpected as clearing history and cache happens during the closing process of Firefox.

It is expected by people familiar with the source code and the implications of the code - but by this metric, all bugs are expected behavior.

> You're assuming that this process happens when Firefox is launched

Not at all - I'm assuming that this process is fit for purpose.

Whether you're a purchasing Christmas presents, browsing pornography or doing something illegal, with these settings your browsing history will be assumed to be invisible to the next person using the browser.
Component: Untriaged → Bookmarks & History
Keywords: dupeme, privacy
I'm moving this to session restore for the first part of triage. The detail of comment 0 makes this sound more like a session restore issue primarily. History may or may not be saved as well, but that's going to be hard to determine until we decide what to do about the session restore issue.
Component: Bookmarks & History → Session Restore
Hi Soren, thanks for filing this bug report!

I'd like to turn this into an enhancement request: When Firefox shut down abnormally (i.e. crashed), `Clear history when Firefox closes` should be performed next time it is successfully started.

You're seeing this issue, because the Firefox process doesn't get enough time to fully remove all history from the operating system (Windows, in your case). The more history you have, the more likely it is you can reproduce this issue.

Since we know when the process has shut down abnormally, we ought to be able to clear data on startup instead.
Blocks: ss-feature
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Keywords: dupeme
Summary: Despite privacy settings, history is kept on close if close was due to a crash or restart → Enforce privacy settings on next startup, when previous application close was due to a crash
Whiteboard: [good-next-bug]
Mentor: mdeboer
This makes sense, but it may break habit and lose data. In addition, whether it should block starts?
OS: Unspecified → All
Hardware: Unspecified → All

Without knowing the codebase or how hard it would be to implement, "enforce on next startup" seems like the wrong approach: Data that shouldn't be remembered shouldn't be written to disk in the first place.

Mentor: mdeboer
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.