Closed
Bug 481786
Opened 16 years ago
Closed 16 years ago
Current session data is getting lost when starting Firefox in "Always On" mode
Categories
(Firefox :: Private Browsing, defect)
Tracking
()
RESOLVED
WONTFIX
Firefox 3.6a1
People
(Reporter: whimboo, Assigned: ehsan.akhgari)
References
Details
(Keywords: dataloss)
Attachments
(1 file)
3.00 KB,
patch
|
zeniko
:
review+
mconnor
:
approval1.9.1-
|
Details | Diff | Splinter Review |
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•16 years ago
|
||
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 | ||
Updated•16 years ago
|
Whiteboard: [has patch][needs review zeniko]
Comment 2•16 years ago
|
||
Comment on attachment 366164 [details] [diff] [review]
Patch (v1)
r+=me, thanks.
Attachment #366164 -
Flags: review?(zeniko) → review+
Assignee | ||
Comment 3•16 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Flags: in-litmus?
Resolution: --- → FIXED
Whiteboard: [has patch][needs review zeniko]
Target Milestone: --- → Firefox 3.2a1
Assignee | ||
Updated•16 years ago
|
Attachment #366164 -
Flags: approval1.9.1?
Comment 4•16 years ago
|
||
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•16 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•16 years ago
|
Attachment #366164 -
Flags: ui-review?(mconnor)
Comment 6•16 years ago
|
||
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-
Comment 7•16 years ago
|
||
>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?
Comment 8•16 years ago
|
||
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: 16 years ago → 16 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 9•16 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?
Comment 10•16 years ago
|
||
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•16 years ago
|
||
Filed as bug 482334.
Assignee | ||
Comment 12•16 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•16 years ago
|
Attachment #366164 -
Flags: ui-review?(mconnor)
Comment 13•16 years ago
|
||
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.
Description
•