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

VERIFIED FIXED in Firefox 3.6a1

Status

()

Firefox
Private Browsing
P2
normal
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: whimboo, Assigned: Away for a while)

Tracking

({verified1.9.1})

3.5 Branch
Firefox 3.6a1
verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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

Comment 1

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

Comment 2

9 years ago
Created attachment 366641 [details] [diff] [review]
Patch (v1)

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

Updated

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

Comment 4

9 years ago
(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 5

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

Comment 6

9 years ago
(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.

Updated

9 years ago
Priority: -- → P2
Target Milestone: --- → Firefox 3.5b4

Updated

9 years ago
Attachment #366641 - Flags: ui-review?(mconnor) → ui-review+
Comment on attachment 366641 [details] [diff] [review]
Patch (v1)

Yeah, this should be fine.
(Assignee)

Comment 8

9 years ago
http://hg.mozilla.org/mozilla-central/rev/5e55ade03f02
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Flags: in-litmus?
Resolution: --- → FIXED
Target Milestone: Firefox 3.5b4 → Firefox 3.6a1
(Assignee)

Updated

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

Comment 11

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

Updated

9 years ago
Keywords: checkin-needed
Whiteboard: [needs 1.9.1 landing]
(Assignee)

Comment 15

9 years ago
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/68a4f9e0fffe
Keywords: checkin-needed → fixed1.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
Keywords: fixed1.9.1 → verified1.9.1
Adding the in-litmus flag as this has now landed on that branch and the test has been enabled.
Flags: in-litmus? → in-litmus+
(Assignee)

Updated

9 years ago
Duplicate of this bug: 495775
You need to log in before you can comment on or make changes to this bug.