706788 - browser.startup.page = 3 interacts strangely with privacy.sanitize.sanitizeOnShutdown

Status: NEW

(Firefox :: Session Restore, defect)

Description

[theimp]

If both browser.sessionstore.enabled is set to true, and privacy.sanitize.sanitizeOnShutdown is set to true, then session restore does not work.

Although it might seem that they make no sense together, in fact they do. Very broadly speaking, sessionstore concerns the current browsing session; while the various sanitizeOnShutdown/clearOnShutdown options concern historic data; History, Form history, etc. (not entirely, but mostly).

The behavior is actually buggy even aside from debates regarding whether on should negate another. What privacy.sanitize.sanitizeOnShutdown actually does, in respect of sessions, is disable all reading and writing of the sessionstore.js file.

So, if privacy.sanitize.sanitizeOnShutdown is set to true while Firefox is running:
1.  Any sessionstore.js remains, uncleared and in plain text, in the profile.
2.  Crashed sessions are not restored.
3.  Editing user.js/prefs.js to turn off privacy.sanitize.sanitizeOnShutdown will restore the last session written before the option was turned on - perhaps months or even years ago.

So, privacy.sanitize.sanitizeOnShutdown should not affect reading to or writing from the sessionstore.js file; that should be entirely in the scope of the browser.sessionstore.enabled option.

Alternatively, this might be reconciled by another privacy setting, such as privacy.clearOnShutdown.browsingSession or similar, to specifically indicate unambiguous behavior.

Comment 1

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to theimp from comment #0)
> If both browser.sessionstore.enabled is set to true, and
> privacy.sanitize.sanitizeOnShutdown is set to true, then session restore
> does not work.

browser.sessionstore.enabled has not been used by Firefox for many versions now (I think 3.0 was the last to use it).

That said, sessionstore & clearing history at shutdown have been at odds with each other for a long time (there's a bug somewhere).

Comment 2

[theimp]

Okay, you're right, sorry, I meant the option browser.startup.page with a value of 3.

I just double-checked it to make sure I wasn't mistaken, and it is indeed the same bug. I obviously just got confused and wrote the wrong preference in the bug report.

Indeed the issue is not new, but I've only just got around to exploring the buggy side-effects.

Comment 3

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to theimp from comment #2)
> Okay, you're right, sorry, I meant the option browser.startup.page with a
> value of 3.

I figured :)

(In reply to theimp from comment #0)
> If both browser.sessionstore.enabled is set to true, and
> privacy.sanitize.sanitizeOnShutdown is set to true, then session restore
> does not work.

That's bug 398817.

> The behavior is actually buggy even aside from debates regarding whether on
> should negate another. What privacy.sanitize.sanitizeOnShutdown actually
> does, in respect of sessions, is disable all reading and writing of the
> sessionstore.js file.
> 
> So, if privacy.sanitize.sanitizeOnShutdown is set to true while Firefox is
> running:
> 1.  Any sessionstore.js remains, uncleared and in plain text, in the profile.

I can't seem to reproduce this.

> 2.  Crashed sessions are not restored.

That is by design - the purge notification is fired at startup following a crash, so we respect that. We do write the file throughout the session though and it's available in your profile... That can definitely be better...

> 3.  Editing user.js/prefs.js to turn off privacy.sanitize.sanitizeOnShutdown
> will restore the last session written before the option was turned on -
> perhaps months or even years ago.

Again, I can't reproduce this since (see 1) I'm not left with a sessionstore.js in my folder, except following a crash.

Comment 4

[theimp]

> I can't seem to reproduce this.

Now I can't either.

It definitely happens, however, if Firefox crashes after enabling the privacy.sanitize.sanitizeOnShutdown preference. I guess it only removes it on shutdown, if it has an open handle to it, which it won't after restoring from a crash, because it'll never have opened it again on startup.

I'll see if I can isolate the behavior that I reported.

> That's bug 398817.

Hm. Missed that one. Sorry.

> I'm not left with a sessionstore.js in my folder, except following a crash.

Still, I guess that this is enough of a bug even if it involves a crash.

Since Bug 398817 seems to indicate that the opinion of the responsible developers is that clearing the history should override saving the session for data security reasons, then, privacy.sanitize.sanitizeOnShutdown should close (and thus remove) sessionstore.js at the instant that it is changed to a value of true. Otherwise, the argument that the behavior is for data security is a bit hollow if it only needs a stray crash (howsoever caused) to break that same security.