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

RESOLVED WONTFIX

Status

()

--
critical
RESOLVED WONTFIX
10 years ago
10 years ago

People

(Reporter: whimboo, Assigned: Ehsan)

Tracking

({dataloss})

3.5 Branch
Firefox 3.6a1
dataloss
Points:
---
Bug Flags:
blocking-firefox3.5 -
in-litmus -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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?
(Assignee)

Comment 1

10 years ago
Created attachment 366164 [details] [diff] [review]
Patch (v1)

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)
(Assignee)

Updated

10 years ago
Whiteboard: [has patch][needs review zeniko]

Comment 2

10 years ago
Comment on attachment 366164 [details] [diff] [review]
Patch (v1)

r+=me, thanks.
Attachment #366164 - Flags: review?(zeniko) → review+
(Assignee)

Comment 3

10 years ago
http://hg.mozilla.org/mozilla-central/rev/9ab865986f27
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Flags: in-litmus?
Resolution: --- → FIXED
Whiteboard: [has patch][needs review zeniko]
Target Milestone: --- → Firefox 3.2a1
(Assignee)

Updated

10 years ago
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-
(Assignee)

Comment 5

10 years ago
I backed out the patch in order to get a proper ui-review.  Sorry for landing it without that.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Updated

10 years ago
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
Last Resolved: 10 years ago10 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 9

10 years ago
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.
(Reporter)

Comment 11

10 years ago
Filed as bug 482334.
(Assignee)

Comment 12

10 years ago
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.
(Assignee)

Updated

10 years ago
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.