Closed Bug 481786 Opened 12 years ago Closed 12 years ago

Current session data is getting lost when starting Firefox in "Always On" mode

Categories

(Firefox :: Private Browsing, defect)

3.5 Branch
defect
Not set
critical

Tracking

()

RESOLVED WONTFIX
Firefox 3.6a1

People

(Reporter: whimboo, Assigned: ehsan)

References

Details

(Keywords: dataloss)

Attachments

(1 file)

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3 ID:20090305133223

When the "Always On" mode gets enabled, the first time the user starts Firefox his last session is shown. After the second start Firefox comes up with a blank tab, which is the expected behavior. But if the user disables this mode at some point and restarts Firefox, the session when the mode was entered has been cleared.

Steps:
1. Open a couple of windows and tab
2. Enable the Always on mode (browser.privatebrowsing.autostart=true)
3. Restart the browser
4. Restart the browser
5. Disable the Always on mode (browser.privatebrowsing.autostart=false)
6. Restart the browser

After step 3 the last session from step 2 is shown. After step 4 Firefox starts with one window and one empty tab. Same happens after step 6, where Firefox should normally should open the session from step 2.
Flags: blocking-firefox3.1?
Attached patch Patch (v1)Splinter Review
With this patch, users non-private session is not restored in "always on" private browsing sessions, and it's not overwritten as well.  Here is the result of this patch on the set of steps to reproduce in comment 0:

After step 3, a blank session (one window with one blank tab) is shown.  After step 4, a blank session is shown (even if you had opened some tabs/windows in step 3).  After step 6, the session from step 2 is shown.
Assignee: nobody → ehsan.akhgari
Status: NEW → ASSIGNED
Attachment #366164 - Flags: review?(zeniko)
Whiteboard: [has patch][needs review zeniko]
Comment on attachment 366164 [details] [diff] [review]
Patch (v1)

r+=me, thanks.
Attachment #366164 - Flags: review?(zeniko) → review+
http://hg.mozilla.org/mozilla-central/rev/9ab865986f27
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-litmus?
Resolution: --- → FIXED
Whiteboard: [has patch][needs review zeniko]
Target Milestone: --- → Firefox 3.2a1
Attachment #366164 - Flags: approval1.9.1?
Comment on attachment 366164 [details] [diff] [review]
Patch (v1)

I don't think this was really a bug... and this should have had ui-review as a user-impacting behaviour change.
Attachment #366164 - Flags: approval1.9.1? → approval1.9.1-
I backed out the patch in order to get a proper ui-review.  Sorry for landing it without that.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #366164 - Flags: ui-review?(mconnor)
So, the net effect of this patch is that if you switch to perma-private browsing mode, and switch back days or weeks down the road, you'll get a session from your distant past.  I don't think that's right, let alone the permanent retention of user data.

I do wonder if we want to offer to clear existing private data when enabling this mode.  Faaborg, thoughts?

(This doesn't block, not least of the reasons is that this is a hidden pref.
Flags: blocking-firefox3.1? → blocking-firefox3.1-
>So, the net effect of this patch is that if you switch to perma-private
>browsing mode, and switch back days or weeks down the road, you'll get a
>session from your distant past.

That behavior seems exceedingly weird.  Also the current session when the use decides to go into "total privacy mode" might actually contain more interesting than normal.

>I do wonder if we want to offer to clear existing private data when enabling
>this mode.  Faaborg, thoughts?

Yeah, offering to clear all existing data seems very consistent with the user's intent.  I'm trying to think of a UI that doesn't involve throwing up a modal dialog after selecting something in a drop down list though.  Maybe an informational sentence and button (hyperlink?) after the mode is switched on in the privacy prefpane?
So I think this bug is WONTFIX or INVALID, I already commented in another bug about filing a bug around the transition to autostart mode, so let's do that.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → WONTFIX
So we also don't care about the first start in always on mode, where the former session instead of a new one is displayed?
That should be covered in the transition to that mode, which should be a new bug.  The problem is that when you set that pref, nothing happens until next start.
I have filed bug 482430 about the transition of the pref.

Please note that handling the transition has nothing to do with not showing the last session upon starting in the always on mode, for which Henrik filed bug 482334.  In fact, I think part of my patch in this bug should fix that bug easily.
Attachment #366164 - Flags: ui-review?(mconnor)
Since this bug has been won't fixed, I am resetting the in Litmus flag to reflect the fact a test case is not needed.
Flags: in-litmus? → in-litmus-
You need to log in before you can comment on or make changes to this bug.