Closed Bug 482430 Opened 16 years ago Closed 16 years ago

Enter private browsing mode as soon as the browser.privatebrowsing.autostart pref is set

Categories

(Firefox :: Private Browsing, enhancement, P2)

Product:
Firefox
Component:
Private Browsing
Type:
enhancement

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Firefox 3.5b4

People

(Reporter: ehsan.akhgari, Unassigned)

References

Details

Follow-up from bug 467565 comment 28. Before we start with the implementation, we should work out the details of how this should work. Also, is it something that we would want for 3.5?
Flags: wanted-firefox3.1?
So how much does it differ from my bug 482334?
(In reply to comment #1) > So how much does it differ from my bug 482334? Ok, I've seen your comment on bug 481786.
So, should we enter the private browsing mode as soon as the pref is set to true? Wouldn't it be weird at least? CCing faaborg here for comment.
Keywords: uiwanted
I don't think it's weird at all. Especially if we had this in the UI expressed like Alex's mockup...
(In reply to comment #4) > I don't think it's weird at all. Especially if we had this in the UI expressed > like Alex's mockup... Yeah, in that case, sure. But imagine this which is what would happen right now: 1. You go to about:config, and find the pref. 2. You double-click it to toggle it. 3. The whole session closes down without any prompts, opening up about:privatebrowsing. 4. You realize that you needed something in your previous session, and you go to the Tools menu, but Stop Private Browsing is disabled. 5. You restart the browser, only to find out that Stop Private Browsing is still disabled. 6. You fire up about:config again, and toggle the pref. The same weird session closing happens again, but you won't get your old session back at all, because we probably had cleared it up behind the scenes at step 3. So, in addition to weird, this is actually a dataloss scenario. Now, one thing which can be done to improve this is adding (yet another) modal prompt after step 2, to confirm what you're doing, and what happens behind the scenes (your current session being deleted), which probably should not be dismissible by a "don't ask me again" for next times. Now this is less weird (still weird because AFAIK no other pref being changed results in a modal dialog). And this seems a bit fragile if you consider the fact that the pref can be toggled by an extension for example: what will happen if the extension does this after user does something in the extension's own modal dialog? Will we be able to safely predict every scenario in which this pref can be toggled?
Blocks: 482334
In fact, this may be safer if we decide to delete the session data the next time that the user starts up the browser, and enter normal private browsing mode after turning on the pref (which leaves the "undo" option open for the user in the original session).
I'm not concerned with the UI being confusing if the user has started to change prefs in about:config. However, for the case of this pref being switched in the privacy prefpane, if we have to do a restart for it to take effect, then we probably want to use a notification bar on the options window similar to the behavior of the add-ons manager.
Priority: -- → P2
Target Milestone: --- → Firefox 3.5b4
(In reply to comment #7) > I'm not concerned with the UI being confusing if the user has started to change > prefs in about:config. However, for the case of this pref being switched in > the privacy prefpane, if we have to do a restart for it to take effect, then we > probably want to use a notification bar on the options window similar to the > behavior of the add-ons manager. Alex, are we going to take the privacy prefpane redesign for 3.5?
>Alex, are we going to take the privacy prefpane redesign for 3.5? Since the back end work is now implemented (the pref browser.privatebrowsing.autostart), it would be great to try to get this in for beta 4. Do you have any free cycles to work on it? If not I'll bring it up at the next development meeting to see if anyone else has time.
(In reply to comment #9) > Since the back end work is now implemented (the pref > browser.privatebrowsing.autostart), it would be great to try to get this in for > beta 4. Do you have any free cycles to work on it? If not I'll bring it up at > the next development meeting to see if anyone else has time. Yes, sure. I remember that you filed a bug about this, but I can't find it right now. Would you mind pointing out the bug ID please?
Whiteboard: [PB-P2]
Nevermind, found it at last! bug 462041.
Why would you close the current session when the autostart pref is set? I think in the autostart case it makes the most sense to just leave the session as is, not even prompt the user, as this is more of an overall privacy/history choice, not a temporary change of session type. Similar to the window title change which does not happen in autostart mode.
I think Nochum has a point here. Alex, what do you think?
I think "autostart" is misleading. Maybe we should have changed the prefname to always_on or something. (yes, I know, I wontfixed that bug, but I'm rethinking it now, because we won't likely get the UI done right) consider something like http://people.mozilla.com/~faaborg/files/shiretoko/privacy_i2.png where it's expressed as a "don't remember anything" behaviour. In that case, we definitely want to have it apply immediately (and probably want to offer to clear data as well) rather than tie to the current implementation of it being a startup pref.
(In reply to comment #14) > consider something like > http://people.mozilla.com/~faaborg/files/shiretoko/privacy_i2.png where it's > expressed as a "don't remember anything" behaviour. In that case, we > definitely want to have it apply immediately (and probably want to offer to > clear data as well) rather than tie to the current implementation of it being a > startup pref. The clear data part was also deemed too big for 1.9.1 (and IMHO that decision might use some re-thinking as well, especially now that we have another beta ahead of us).
>consider something like >http://people.mozilla.com/~faaborg/files/shiretoko/privacy_i2.png where it's >expressed as a "don't remember anything" behaviour. In that case, we >definitely want to have it apply immediately (and probably want to offer to >clear data as well) rather than tie to the current implementation of it being a >startup pref. I've been thinking about the case where the user doesn't really expect all of their tabs to close as soon as they flipped the drop down list to the "don't remember anything" option, but at the same time they also expect the choice to take immediate effect after hitting ok. So off the top of my head it seems like a notification bar in the options window saying that you need to restart (similar to the add-ons manager) is one way of getting around this problem. A cleaner approach (in terms of the interaction) is to put the browser into private browsing mode, and clone the current tab set, although wouldn't that be prone to potential dataloss? In the case of the user changing options in about:config, how do we deal with with other preferences that only take effect on restart? My impression is that we don't do anything, assuming the user understands the pref, so we would just continue that precedent for browser.privatebrowsing.autostart (or whatever we name it).
(In reply to comment #14) > I think "autostart" is misleading. Maybe we should have changed the prefname > to always_on or something. (yes, I know, I wontfixed that bug, but I'm > rethinking it now, because we won't likely get the UI done right) Just for x-ref - this is/was bug 471998.
(In reply to comment #16) > I've been thinking about the case where the user doesn't really expect all of > their tabs to close as soon as they flipped the drop down list to the "don't > remember anything" option, but at the same time they also expect the choice to > take immediate effect after hitting ok. So off the top of my head it seems > like a notification bar in the options window saying that you need to restart > (similar to the add-ons manager) is one way of getting around this problem. A > cleaner approach (in terms of the interaction) is to put the browser into > private browsing mode, and clone the current tab set, although wouldn't that be > prone to potential dataloss? Why clone the current tab set? I'd say that a cleaner approach would be to just leave the session open without any change and just turn on the private browsing mode behind the scenes.
>I'd say that a cleaner approach would be to >just leave the session open without any change and just turn on the private >browsing mode behind the scenes. Sorry, I got confused with our inability to have separate private browsing windows. So the issue isn't that we can't transition a session to private browsing, but rather that we can't have private and non-private windows open simultaneously? If that is the case then yeah, we should definitely just turn private browsing mode on behind the scenes.
(In reply to comment #19) > Sorry, I got confused with our inability to have separate private browsing > windows. So the issue isn't that we can't transition a session to private > browsing, but rather that we can't have private and non-private windows open > simultaneously? If that is the case then yeah, we should definitely just turn > private browsing mode on behind the scenes. Ah, if in comment 18 you were talking about opening a new window in private browsing mode, then yes, we can't do that yet. So I guess the confusion is over. :-) But still, I don't think this is something which should happen upon setting the pref; I think the privacy pref pane control should do this, and the pref should continue to take affect on restarting. I guess you agree based on comment 16. And this means WONTFIXing this bug. :-) One other UX question. On platforms which don't have an OK button on the preferences dialog (such as Linux), would we want to switch to private browsing mode right after the option is selected from the menu? This may be a bit strange especially if the user is merely playing with the menu. It is still possible; just confirming what the interaction here should be.
>But still, I don't think this is something which should happen upon setting the >pref; I think the privacy pref pane control should do this, and the pref should >continue to take affect on restarting. That sounds fine. It would be nice if these types of prefs in about:config displayed a reset required notification bar, but that is pretty much the lowest priority UI improvement amongst all possible UI improvements :) >One other UX question. On platforms which don't have an OK button on the >preferences dialog (such as Linux), would we want to switch to private browsing >mode right after the option is selected from the menu? This may be a bit >strange especially if the user is merely playing with the menu. Yeah, I think we need to switch immediately, will there be any noticeable effect for the user?
(In reply to comment #21) > >One other UX question. On platforms which don't have an OK button on the > >preferences dialog (such as Linux), would we want to switch to private browsing > >mode right after the option is selected from the menu? This may be a bit > >strange especially if the user is merely playing with the menu. > > Yeah, I think we need to switch immediately, will there be any noticeable > effect for the user? If you mean things like the current session being closed, then no. The user visible effects would be the fact that the Stop Private Browsing menu item would get disabled, which is not _that_ user noticeable. :-) WONTFIXing as per the discussion in this bug.
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: wanted-firefox3.5?
Keywords: uiwanted
Resolution: --- → WONTFIX
Whiteboard: [PB-P2]
You need to log in before you can comment on or make changes to this bug.