Closed Bug 482334 Opened 15 years ago Closed 15 years ago

Entering "always on" mode of Private Browsing should not show last session

Categories

(Firefox :: Private Browsing, defect, P2)

3.5 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 3.6a1

People

(Reporter: whimboo, Assigned: ehsan.akhgari)

References

Details

(Keywords: verified1.9.1)

Attachments

(1 file)

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
Whiteboard: [PB-P3]
Attached patch Patch (v1)Splinter Review
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.
Attachment #366641 - Flags: ui-review?(mconnor)
Attachment #366641 - Flags: review?(zeniko)
Whiteboard: [PB-P3]
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+
Comment on attachment 366641 [details] [diff] [review]
Patch (v1)

Yeah, this should be fine.
http://hg.mozilla.org/mozilla-central/rev/5e55ade03f02
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-litmus?
Resolution: --- → FIXED
Target Milestone: Firefox 3.5b4 → Firefox 3.6a1
Attachment #366641 - Flags: approval1.9.1?
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+
Keywords: checkin-needed
Whiteboard: [needs 1.9.1 landing]
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/68a4f9e0fffe
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.

Attachment

General

Created:
Updated:
Size: