Closed Bug 482334 Opened 14 years ago Closed 14 years ago
Entering "always on" mode of Private Browsing should not show last session
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090305 Shiretoko/3.1b4pre ID:20090305020312 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. Steps: 1. Open a couple of windows and tab 2. Enable the Always on mode (browser.privatebrowsing.autostart=true) 3. Restart the browser After step 3 the last session is shown instead of a window with a blank tab.
Taking over, as part of my patch in bug 481786 would cover this. I'll try to prepare the patch for review here later today.
Assignee: nobody → ehsan.akhgari
Status: NEW → ASSIGNED
Simon, you have already reviews this as part of the patch in bug 481786; I'm just requesting your review for the record. Mike, I'd like to have your ok on this patch from the UI perspective. Please note that this with this patch, the first time a user starts in auto-start PB mode, the old session is not resumed, but as soon as the user quits the application, the original sessionstore.js data in the profile would get overwritten with an empty session. This part should be handled as part of bug 482430.
Comment on attachment 366641 [details] [diff] [review] Patch (v1) this doesn't solve the problem that session data is lying around that may not be useful later on, and will be restored if and when you disable this mode.
(In reply to comment #3) > (From update of attachment 366641 [details] [diff] [review]) > this doesn't solve the problem that session data is lying around that may not > be useful later on, and will be restored if and when you disable this mode. Yes, because I'm not really sure what we should do here (and therefore left it to bug 482430). Should we delete it right after the auto-start mode is turned on? Or after the first time that the browser starts in that mode (if this lands before bug 482430)?
Depends on: 482430
Comment on attachment 366641 [details] [diff] [review] Patch (v1) Code-wise this is still fine. As for the UX, do we have a design document for how the whole autostart related interaction is supposed to work?
Attachment #366641 - Flags: review?(zeniko) → review+
(In reply to comment #5) > (From update of attachment 366641 [details] [diff] [review]) > Code-wise this is still fine. As for the UX, do we have a design document for > how the whole autostart related interaction is supposed to work? No, I'm afraid not. There is a discussion in bug 482430 though, which may lead into one.
Priority: -- → P2
Target Milestone: --- → Firefox 3.5b4
Attachment #366641 - Flags: ui-review?(mconnor) → ui-review+
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: Firefox 3.5b4 → Firefox 3.6a1
Verified fixed on the trunk using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090505 Minefield/3.6a1pre.
Status: RESOLVED → VERIFIED
Ehsan, now with the change that we directly change into always on mode do we still need this patch on 1.9.1?
(In reply to comment #10) > Ehsan, now with the change that we directly change into always on mode do we > still need this patch on 1.9.1? Yes, of course. Setting the pref directly still takes effect after restarting.
https://litmus.mozilla.org/show_test.cgi?id=7703 added to Litmus.
Flags: in-litmus? → in-litmus+
Marcia, this Litmus test should not be enabled until the bug is fixed on 1.9.1. I'll disable it meanwhile.
Flags: in-litmus+ → in-litmus?
Comment on attachment 366641 [details] [diff] [review] Patch (v1) a191=beltzner
Attachment #366641 - Flags: approval1.9.1? → approval1.9.1+
Whiteboard: [needs 1.9.1 landing]
Verfied fixed on 1.9.1 for all three platforms: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090517 Shiretoko/3.5b5pre (.NET CLR 3.5.30729) ID:20090517065612
Adding the in-litmus flag as this has now landed on that branch and the test has been enabled.
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.