505548 - No warning about contradictory "Clear history" and "Show my windows/tabs from last time" options when quitting or restarting

Status: NEW

(Firefox :: Settings UI, defect, P3)

Description

[Marcus P S]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1

If the user chooses "Show my windows/tabs from last time" from the "Security" preferences and "Clear history" from the "Main" preferences, at no point there is a warning that information about the open windows/tabs will be wiped out.

If a user updates his addons, or updated Firefox (such as in the case of the recent security update), the user may loose his data if his expectations are different from what the developers decided was expected behaviour.

Note that this is a change in behavior from the previous version of Firefox, and therefore has caused many users to loose data after performing updates.

Reproducible: Always

Steps to Reproduce:
1. Chooses "Show my windows/tabs from last time" from the "Security" preferences and "Clear history" from the "Main" preferences
2. Open several windows and tabs at various websites.
3. Quit the browser, or restart the browser after adding a new addon.
4. Restart the browser.
Actual Results:  
When the browser quits, there is no dialog box that indicates the user will lose all the open tabs and windows.

Expected Results:  
The user should at least get a dialog indicating the contradiction in the options, and allowing to abort in order to save the data or change the options.

If the user had similar options from the previous version, he/she may expect that the session should be restored without a problem, even though he/she selected for the history to be cleared.

Although some may argue that security privacy issues override the more specific options to restore the last session, it is clear that the expectation of many is that the session will be restored despite the privacy setting (however illogical many may think it is).

Instead of arguing which interpretation of the options is more logical, the browser should help the user ensure that he does not lose his data.

Ideally, the warning dialog box could have a "Don't ask me again" option, since the warning appears redundant to some. But to others it is not, and the large number of bugs filed in this respect is clear evidence of that.

I am filing the big under "critical" because it has caused many users to lose data.

Comment 1

[tomgottfried]

I fall into that trap too and, really, there are so many bug reports that seem to show up confusion caused by that change in behaviour between 3.0 and 3.5!

But I don't think that users who have been used to use the feature of having their open windows and tabs restored in the next session will be happy with just a warning, saying this feature is missing now (at least not me).
And the behaviour in 3.0 was not illogical. I would rather consider the "Show my windows/tabs from last time" as an extremely useful exception regarding the "Clear history". In 3.5 the only way to achieve the same effect, is to disable automatic deleting of the history and doing it manually every time before quitting Firefox, which I consider as a step backwards and a "loss of feature".

As it is possible for the user to apparently set two preferences that in fact are mutually exclusive and the effect is explained to the user neither on the GUI nor in the knowledge base, I would consider it as a bug, even if it had been like that in previous versions of Firefox.

To be more precise about the versions: The feature works for me in 3.0.13 and does not in 3.5.2 (both on Mac OS X 10.4.11).

Comment 2

[armillaria]

I don`t like to change to 3.5.X until this bug is fixed.

Comment 3

[wayne_mahl2000]

(In reply to comment #0)

I am also experiencing this bug. It is caused when firefox clears 'browsing history' upon closing. If I disable the option to clean browsing history, Firefox saves my open tabs as normal, otherwise it says it will save the tabs but then doesn't open them again when firefox is reopened.

Also if I have firefox on the 'save my windows and tabs from last time' it doesn't even ask to save tabs.

Comment 4

[Craig Markwardt]

I confirm this bug is still present in Firefox 4.0b10 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10) Gecko/20100101 Firefox/4.0b10).

User's should not be allowed to select "Show my windows/tabs from last time" if the history will be cleared and there will be no windows or tabs to display.

Comment 5

[heraldo]

Attachment: confusing browsing history terms in the Privacy Prefs tab

IMO this issue is also about the confusing "browsing history" terms used in the Privacy Prefs tab.

1. Checking "Clear Browser History on exit" deletes the session
2. Having the former unchecked and "Remember my browsing history" unchecked keeps the session
3. Deleting Browsing & Download History from Tools > Clear recent history keeps the session

There could be an additional checkbox for "Remember my open tabs and windows" in the Privacy Prefs tab, in the "Settings for clearing history" dialog and in Clear recent history dialog.

Comment 6

[heraldo]

Attachment: demo with pass conditions and proposed fix

Comment 7

[[e-mail]]

Bug 803806 seems to overlap, someone worried about privacy and sessionstore.js and sessionstore.bak

My config = Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20130312 Firefox/22.0 ID:20130312031046 CSet: 7433bc4545c9

Settings for closing history popup window per sequence
Options > Privacy > Clear history when nightly closes [checked] > Settings

If "active logins" and "browsing history" are unchecked, but the "Clear history when Nightly closes" is checked along with Options > General > show my windows and tabs from last time (did NOT trouble shoot with "active logins" checked but "browsing history" unchecked) -

then
sessionrestore.js and sessionrestore.bak are kept intact, and on relaunch session is restored

If "settings" popup has "browsing history" checked, then a RESTART (using restartless restart addon) works, keeping the sessionrestore.js intact, but if do an exit and a restart using a Windows shortcut or command line launch with "-no-remote -P" switches set, and choosing the exited profile from the profile manager, then get in the profile directory a reset of sessionstore.js to 1K w/o exited data, and no sessionstore.bak

The fix has to be in decoupling the clear history on closing, impacting sessionstore.js (something Bug 803806 author does not want apparently for forensic privacy reasons). 

As other posting noted, using app button > history > clear recent history > time range everything and "browser history and downloads" checked [equivalent to using tools menu if menu bar used] then sessionrestore.js and sessionrestore.bak are not wiped clean.

Note, coding has to differ, if going via options vs going via app button [or tools menu], in that options >> settings gives separate download and browsing history clear on exit choice; whereas clearing via app button [tools menu] clears downloads and browser history as a coupled choice.

Again - bug seems to be whacking sessionrestore.js and sessionrestore.bak if using the options >> approach, vs not whacking them if using the app button >> approach. 

Comments here seem to favor decoupling "options >> clear on closing" to NOT clear and reset sessionrestore.js in the process

Suggest consider Bug 803806 and this one as a policy question first, session integrity vs hyper-privacy worry; but fix how current code zero's out and resets the sessionrestore.js file

Comment 8

[[e-mail]]

more troubleshooting =
In about:config, search = privacy.clear, the user set variable settings needed to prevent session loss on exit/restart are:

privacy.clearOnShutdown.history >> false
privacy.clearOnShutdown.sessions >> false

(it seems other related variables can be left default AND having ...history = true, and only ...sessions = false DOES NOT preserve session integrity)

I believe in parallel, in about:config, the setting to start where last session ended is

browser.startup.page -- user set -- integer = 3

Not 100% sure, but it seems homepage startup is "1" and blank page startup is "0" (with it being a guess what "2" gets).

If anybody believes this is incorrect or incomplete, please help with a correction/comment.

Comment 9

[[e-mail]]

Further troubleshooting
Using a new profile, (no addons), Nightly current up-to-date, toggling about:config privacy.xxx settings but keeping on-atartup set to resume last session, i.e.,
browser.startup.page > user set = 3

privacy.clearOnShutdown.sessions could be toggled either way, BUT key was:

privacy.clearOnShutdown.history > false = sessionstore.js okay, session resumes

privacy.clearOnShutdown.history > true = on exit/startup, get homepage, session lost

Comment 13

[Andre]

Lost all my tabs. I can confirm this bug in 48.0.2

Comment 15

[Nik Tree]

Hey, all these bugs addressing the same settings confusion regarding history settings and session persistence:

• bug 505548 (opened 11 years ago - this bug)
• bug 1022231 (opened 6 years ago - I reported here two days ago)
• bug 1417150 (opened 3 years ago)
• bug 1453378 (opened 2 years ago)
• bug 1645161 (opened 2 months ago)

I don't know who to address here to have a look in this and maybe merge these bug reports but I think we all agree that the result should be a better protection of data loss through these inter-dependent preferences options.

And sorry if this redundant posting is annoying to somebody, I only wanted to address the duplicate issue, since I maybe wrote in the wrong bug report in the first place.

Comment 16

[Petruta Horea [:phorea], Desktop Test Engineering]

Setting severity to S3 since this still happens on newer Firefox versions, but the data loss mentioned affected users upgrading to Firefox 3.5 at the moment this issue was filled.

Comment 17

[:Gijs (out for now; he/him)]

This needs a decision about the desired behaviour and communication to the user.

Comment 18

[Mike Conley (:mconley) (:⚙️)]

Hey rtestard, are there any PM cycles to give us some guidance on how to proceed here?

Comment 19

[Romain Testard [:RT]]

I added to product backlog, this will be triaged for guidance

Comment 20

[Mike Conley (:mconley) (:⚙️)]

In lieu of pending PM guidance, I'm setting a Severity of S3 for now as this is a non-default configuration, and the workaround is (for now) to not clear history on closing the session if the user expects the session to be restored on startup.

Setting P3. These are just placeholders to get this out of the engineering triage queue until we get guidance from PM.

Comment 21

[Mike Conley (:mconley) (:⚙️)]

Adding the dataloss keyword because in the worst-case, the user result here is loss of valuable session date.

Comment 22

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates and 17 votes.
:jaws, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.