build Id: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090611 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090611044033 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090611 Shiretoko/3.5pre (.NET CLR 3.5.30729) ID:20090611041816 and the Beta Preview Release build screencast: http://www.screencast.com/users/ahdesai/folders/Jing/media/c0884a8c-9e68-4fd2-adc0-fc7fca514786 Steps to Reproduce: 1. Open a new profile, surf to some websites in different tabs 2. Quit out of the session and select the "Don't Ask me Next Time" checkbox. 3. Re-open Fx with the profile from step 1. (Make sure the default homepage and a single tab show up on start). 4. Surf to some websites again and Start PB mode. 5. Quit out of Fx. 6. Re-Open Fx with the same profile. Actual Results: The pages surfed to before entering private browsing mode show up. Expected Results: The user's option to "Quit" and not "Save and Quit" should be respected when going back to normal mode.
Summary: Quit is not respected by Private Browsing Mode on Re-Start → User preference for Default Session on Start Up is not respected by Private Browsing Mode on Re-Start
AFAIK this is intentional, see bug 482334.
This feature needs a bit more refined towards the user's preferences as, like the steps to reproduce show, the user doesn't want Fx to return to their previous session in any state with multiple tabs. Yet, that's what it does when they exit out of FX while in PB mode.
(In reply to comment #1) > AFAIK this is intentional, see bug 482334. No, this is not intentional. When quitting, we should nuke out the sessionstore data when inside the private browsing mode as long as browser.startup.page is not equal to 3.
Assignee: nobody → ehsan.akhgari
Status: NEW → ASSIGNED
Created attachment 388462 [details] [diff] [review] Patch (v1)
Attachment #388462 - Flags: review?(zeniko)
Comment on attachment 388462 [details] [diff] [review] Patch (v1) >+ // make sure to restore the non-private session upon resuming >+ this._prefBranch.setBoolPref("sessionstore.resume_session_once", true); Nit: When _doResumeSession returns true, this isn't needed anymore. r+=me codewise, but please also get ui-r for this change, as this could turn into a dataloss issue: when closing Firefox in non-private mode, you get the "Save Tabs and Quit" prompt which gives you the option to save your tabs. AFAICT we don't get that same prompt when closing Firefox in private mode, or do we?
Attachment #388462 - Flags: review?(zeniko) → review+
Created attachment 388657 [details] [diff] [review] Patch (v2) On second thought, I think we should always save the normal session when quitting from the private browsing mode unless the user has previously specified the Quit option on the "Save Tabs and Quit" prompt and has also asked not to be prompted again (therefore, finalizing her decision.) The new patch does that. Asking for ui-r from Alex. Asking for review from Simon again. Note that now we need to set resume_session_once because it might not always be set to true.
>On second thought, I think we should always save the normal session when >quitting from the private browsing mode unless the user has previously >specified the Quit option on the "Save Tabs and Quit" prompt and has also asked >not to be prompted again (therefore, finalizing her decision.) In the technical sense launching Private Browsing mode is "quitting and restarting Firefox" but I'm not sure that this is how users necessarily picture the current behavior of private browsing mode. It is meant as more of a temporary and momentary state in between opening and closing the application as a whole. So if we view private browsing as a "temporary mode" as opposed to being an instance of launched Firefox, then the user's preference for saving or not saving their tabs shouldn't actually come into play. Also note that when you are in private browsing mode you can use the command "stop private browsing" from the tools menu, which is conceptually different from shutting the browser down. The other thing that I am worried about is that even if the user has opted to throw away their session when closing, doing this when momentarily entering into private browsing mode introduces another barrier to entry. The user might think "I don't want to go into private browsing mode right now because I am still using this set of tabs, and throwing it all away is too costly." So I recommend we keep the current behavior, and then in the future ultimately solve (or perhaps side step) the problem by allowing for separate private browsing windows once we get multiple processes working.
WONTFIXing based on Alex's comment 7. It's fine by me given the scenarios Alex mentioned, although I agree that ultimately the desired behavior is to have separate private browsing windows anyway.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.