Closed
Bug 482334
Opened 16 years ago
Closed 15 years ago
Entering "always on" mode of Private Browsing should not show last session
Categories
(Firefox :: Private Browsing, defect, P2)
Tracking
()
VERIFIED
FIXED
Firefox 3.6a1
People
(Reporter: whimboo, Assigned: ehsan.akhgari)
References
Details
(Keywords: verified1.9.1)
Attachments
(1 file)
(deleted),
patch
|
zeniko
:
review+
mconnor
:
ui-review+
beltzner
:
approval1.9.1+
|
Details | Diff | Splinter Review |
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•16 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•16 years ago
|
||
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•16 years ago
|
Whiteboard: [PB-P3]
Comment 3•16 years ago
|
||
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•16 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•16 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•16 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•16 years ago
|
Priority: -- → P2
Target Milestone: --- → Firefox 3.5b4
Updated•15 years ago
|
Attachment #366641 -
Flags: ui-review?(mconnor) → ui-review+
Comment 7•15 years ago
|
||
Comment on attachment 366641 [details] [diff] [review]
Patch (v1)
Yeah, this should be fine.
Assignee | ||
Comment 8•15 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-litmus?
Resolution: --- → FIXED
Target Milestone: Firefox 3.5b4 → Firefox 3.6a1
Assignee | ||
Updated•15 years ago
|
Attachment #366641 -
Flags: approval1.9.1?
Comment 9•15 years ago
|
||
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
Reporter | ||
Comment 10•15 years ago
|
||
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•15 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.
Comment 12•15 years ago
|
||
https://litmus.mozilla.org/show_test.cgi?id=7703 added to Litmus.
Flags: in-litmus? → in-litmus+
Reporter | ||
Comment 13•15 years ago
|
||
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 14•15 years ago
|
||
Comment on attachment 366641 [details] [diff] [review]
Patch (v1)
a191=beltzner
Attachment #366641 -
Flags: approval1.9.1? → approval1.9.1+
Assignee | ||
Updated•15 years ago
|
Keywords: checkin-needed
Whiteboard: [needs 1.9.1 landing]
Assignee | ||
Comment 15•15 years ago
|
||
Keywords: checkin-needed → fixed1.9.1
Whiteboard: [needs 1.9.1 landing]
Reporter | ||
Comment 16•15 years ago
|
||
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
Comment 17•15 years ago
|
||
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.
Description
•