Session Restore On Demand + Privacy
Paul O’Shannessy
previous session on demand at startup. There are 2 problems with it,
(1) is discoverability and (2) is privacy. Discoverability is great to
have, but I'm not going to fret about the specifics here. As is, there
will be a menu item in the history menu to restore your previous
session. If you want to talk about it more, chime in on bug 593421.
Privacy is what I really wanted to talk about and get some feedback.
As it's written, we will save your session to disk every time you
quit, even if your current pref is to show your home page (or blank
page) at startup. If your pref is already to restore your session at
startup, then nothing has changed for you.
The concern comes in that your last session is going to be sitting
around on disk when the user probably didn't expect that. There are a
couple possibilities here.
1. Just go with it. Most of this data is stored elsewhere in your
profile anyway. Cookies and form data are the main concern. Dietrich's
example: "that half-typed screed against the boss is still sitting on
the hard drive, even though you thought it disappeared forever when
you closed the browser...". Session cookies could also cause some
issue, though those require an action in the browser to restore.
2. Add a hidden pref to opt-out for the people who care.
3. Add a visible pref.
a. Put it in Preferences > privacy > Firefox will... > use custom
settings > (check the box that says "clear history when firefox
quits") > settings > another checkbox
b. Put it in Preferences > general > startup...
3a is pretty gross & undiscoverable
3b is less gross - Much like http://skitch.com/zpao/dingk/general
4. Other ideas I haven't thought of?
My personal preference here is just to do 2. It's easy and the people
who care about this, are going to be able to change it.
Thoughts?
Ehsan Akhgari
next time that they open the browser, right? Why can't we use that pref?
Ehsan
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Asa Dotzler
> On Fri, Sep 3, 2010 at 12:35 PM, Ehsan Akhgari<ehsan....@gmail.com> wrote:
>> We do ask the user whether they want us to save their session for the
>> next time that they open the browser, right? Why can't we use that pref?
>>
>> Ehsan
>
> (bug 592822). The dialog that's shown at shutdown sets
> browser.session.resume_session_once if you save but don't check the
> box; browser.startup.page if you save& check the box;
> browser.tabs.warnOnClose/warnOnRestart if you quit& check the box.
>
> There are currently 2 prefs that if set will save your session at
> shutdown - browser.startup.page = 3 and
> browser.sessionstore.resume_session_once = true. If either of those
> are set at startup, we will resume your session automatically, just
> like we behave currently. The plan is to ignore those prefs at
> shutdown but keep their behavior for startup, so we can't really reuse
> either.
We currently keep around lots of their session on disk whether or not
they want it -- unless they use private browsing mode. See History,
Cache, Awesomebar, etc.
I don't think this is much different than that if we let them opt out
somewhere in prefs.
- A
Boris Zbarsky
> In bug 588482, I've been working on making it possible to restore your
> previous session on demand at startup. There are 2 problems with it,
> (1) is discoverability and (2) is privacy. Discoverability is great to
> have, but I'm not going to fret about the specifics here. As is, there
> will be a menu item in the history menu to restore your previous
> session.
This is eerily related to an issue I wanted to ask about anyway, based
on a conversation I had today.
Say I have a reasonably large saved session S1 and my browser is not
currently running. It would be very useful to have a way to start the
browser _without_ restoring S1 but usingthe bookmarks and history from
that profile, do a few things, then quit. Then the next time I start
the browser, restore S1.
I can fake it for myself using Sync and separate profiles and a
shellscript or two, I think, but that's not a great solution for most users.
-Boris
Robert Kaiser
> Say I have a reasonably large saved session S1 and my browser is not
> currently running. It would be very useful to have a way to start the
> browser _without_ restoring S1 but usingthe bookmarks and history from
> that profile, do a few things, then quit. Then the next time I start the
> browser, restore S1.
That would be very cool indeed. I had those cases where I needed to look
up something on the web fast in the morning, after booting the computer,
before departing somewhere, but didn't want to launch my whole usual
session with dozens of tabs which take a while to load.
I usually resort to launching a different profile or browser (!) for
that right now, which is clearly not optimal.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
Dao
> We currently keep around lots of their session on disk whether or not
> they want it -- unless they use private browsing mode. See History,
> Cache, Awesomebar, etc.
>
> I don't think this is much different than that if we let them opt out
> somewhere in prefs.
There's significantly more exposure. Users could walk up to your
computer and, rather than having to wade through your history, would be
presented with an option to restore your tabs.
Alex Faaborg
Viewing the list of page titles and favicons in the Library window
seems equally revealing to me. If you are trying to discover what
someone has been up to and they didn't use private browsing, it's
going to be trivially easy to do so with either approach (library
versus session restore). since we don't hit the network with the
library approach, that might actually be faster.
The current dialog box asking users if they want to save on exit has a
few problems:
-users might not actually know if they want the session later, when
later is now they will have more context to answer the question
-the forced choice doesn't support undo
-the forced choice jumps in the users way after they have explicitly
told Firefox to go away, making the interaction of closing the app
awkward and slow. For a moment the use says close and Firefox says
"no, actually I am not going to"
I agree that doscoverability of this feature will be an issue until we
land the home tab, but otherwise I think removig the forced choice on
close provides the user with more control and a streamlined
interaction.
Alex
John Bird
these choices:
a - 100 tabs - open these with BarTab enabled. Can run Firefox with other
programs running, as uses only 300-400MB memory. TabCandy misbehaves
oddly. eg open a new tab always gives me a new window with only that one
tab, never joins an existing group. Some tabs never join their group or
any group. What misbehaves changes unpredictably from one build to another.
b - 100 tabs and turn Bartab off. Cannot run anything else large. Slowest
startup. 1.2GB memory use. Only way I can get TabCandy working more or
less with full current features (and bugs).
c - Start a new session with 1 tab. Means I permanently lose my 100 tabs,
cannot save them sorted into groups at present for later retrieval, so I
lose them. I can bookmark all tabs but then I lose all the Groups.
Cannot face that - after a whole lot of tabs is the main reason for
TabCandy.
3 - Do temporary quick browsing in Chrome or Opera. That's what I am doing
at present. Cannot get at my bookmarks.
Ability to at least save working Tab Groups and reload them in future is
both a good feature, and a very useful feature for testing TabCandy!!!
John Bird
Dao
> I don't really buy into the arguement of privacy through obscurity.
> Viewing the list of page titles and favicons in the Library window
> seems equally revealing to me. If you are trying to discover what
> someone has been up to and they didn't use private browsing, it's
> going to be trivially easy to do so with either approach (library
You don't need bad intentions, you don't need to /try to discover/ if
you're explicitly asked to restore the previous session's tabs.
John Bird
guessing D2D additions confusing what is causing what to misbehave.
Todays experience was extremely nasty - I thought I was going to be stuck
unable to run Firefox, unable to update, unable to alter addons:
-I have 148 tabs at present, and have been running with BarTab turned on.
I noticed when I created a new tab (CTRL+T) it appeared in a new window
always, so I was wondering if it would behave if I turned BarTab extension
off and restarted.
-Restarting took 15 minutes, and hung. I restarted Firefox several times
all with similar symptoms - after a lightning fast start where Firefox
appeared in a few seconds and the first group of tabs loaded in a few
seconds very fast, the CPU went up, and Firefox went unresponsive.
Clicking a menu would take up to several minutes to respond. Almost no more
pages rendered, and the tab groups showed the group boxes and tab piles, but
no rendered thumbnails.
Downloading an update - which was 2.5MB took about 20 minutes on fast
broadband. All the while the CPU raced away doing obviously nothing.
-Safe mode seemed free of the worst of the slowdowns, but took several times
before it would render the addons page. Obviously something was sick.
-My eventual solution was to re-enable Bartab, while not behaving perfectly
it cured the CPU maxing out.
I have noticed:
-CTRL+T (create new tab) seems to create a window by itself.
-The Group your Tabs icon has disappeared again from the chrome. I added it
back by customising, well that was OK.
John Bird
Michael Lefevre
> Performance has been wildly up and down with nightly builds, with I am
> guessing D2D additions confusing what is causing what to misbehave.
>
> Todays experience was extremely nasty - I thought I was going to be
> stuck unable to run Firefox, unable to update, unable to alter addons:
Yes, there are multiple bugs about the slowness (bug 593361, bug 593268
seem to be key ones), and a couple of fixes on the way which will
hopefully deal with the issues (possibly not all of the issues, but it's
hard to know until they at least are fixed).
In the mean time, you could either revert to a nightly from last week,
or switch the acceleration off (with the layers.accelerate-all and/or
gfx.direct2d.disabled prefs). Or you can continue bearing with the nasty
performance and report additional issues :)
Drifting further off the original topic, I'm not sure what the situation
is with performance testing with the accelerated video stuff is. It
doesn't seem entirely useful to be worrying about 2% regressions in
performance measured in milliseconds, when basic things like opening a
menu, or the tab (and tabcandy) animations become 800% to 3000% slower
and not much happens (not the issues aren't being worked on, but not
with the same priority...). I guess a basic level of work needs to be
done first, but will there be performance tests on that stuff in future?
Michael
Mike Beltzner
> This is eerily related to an issue I wanted to ask about anyway, based on a conversation I had today.
Off topic for the question at hand - please either start another thread here, or file a bug, or both, but let's not split the conversation.
cheers,
mike
Mike Beltzner
> I agree that doscoverability of this feature will be an issue until we land the home tab
s/land the home tab/find a better way to expose it in the UI, which may not admittedly be until after Firefox 4.
(please don't make references to designs that haven't been finalized and aren't in scope for Firefox 4, as I fear it only adds confusion to the discussion at hand which is what we want to do for Firefox 4 itself)
cheers,
mike
Adam Kowalczyk
> I don't really buy into the arguement of privacy through obscurity.
> Viewing the list of page titles and favicons in the Library window
> seems equally revealing to me. If you are trying to discover what
> someone has been up to and they didn't use private browsing, it's
> going to be trivially easy to do so with either approach (library
> versus session restore). since we don't hit the network with the
> library approach, that might actually be faster.
>
> The current dialog box asking users if they want to save on exit has a
> few problems:
>
> -users might not actually know if they want the session later, when
> later is now they will have more context to answer the question
On the other hand, I might not remember what tabs I had when I closed
the browser the day before and if there was something left for me to
read or deal with. Firefox used to show the session restore dialog at
startup (or maybe it was an extension I used?) and I used to find it
annoying because of the above problem - I just didn't remember whether I
needed to restore the previous session or not.
Mike Beltzner
> Privacy is what I really wanted to talk about and get some feedback.
> As it's written, we will save your session to disk every time you
> quit, even if your current pref is to show your home page (or blank
> page) at startup. If your pref is already to restore your session at
> startup, then nothing has changed for you.
For some historical context: when we first implemented session restore, we chose to opt on the side of privacy largely because we didn't have a private browsing mode at that time. The idea of having the option to restore one's session at startup time had been proposed - especially once Safari implemented their feature that way. At the time, the product decision was made to keep the decision at shut-down time mostly for privacy reasons. While the same information was accessible through other UI mechanisms (browser history, cookies, etc) the idea of having a one-click "see what the previous user was doing when they shut down the browser" was an entirely different feeling of privacy invasion.
Now that we have Private Browsing, that should be the recommended mode of preventing someone from snooping on what you were doing before logging in.
The only remaining privacy concern I have is that currently, by default, we restore session-scoped cookies and SSL sessions when restoring a session. Many users may believe that they are logged out of their banking website or email program when they close their browser, and currently, those sessions may be restored on a subsequent startup. I believe that needs to be addressed for this change to make sense. I also believe that a (hidden) pref should be created that allows those states to be restored for those of us (developers, primarily, I suspect) who really like that behaviour.
Overall, I'm more concerned with discoverability than privacy at this point.
That said: "2" is a good option, if not "1".
cheers,
mike
Nathan Tuggy
> Boris Zbarsky schrieb:
>> Say I have a reasonably large saved session S1 and my browser is not
>> currently running. It would be very useful to have a way to start the
>> browser _without_ restoring S1 but usingthe bookmarks and history from
>> that profile, do a few things, then quit. Then the next time I start the
>> browser, restore S1.
>
> That would be very cool indeed. I had those cases where I needed to look
> up something on the web fast in the morning, after booting the computer,
> before departing somewhere, but didn't want to launch my whole usual
> session with dozens of tabs which take a while to load.
>
> I usually resort to launching a different profile or browser (!) for
> that right now, which is clearly not optimal.
>
> Robert Kaiser
>
I do the same thing -- I have a profile specifically for "light-weight"
browsing (even though my computer is on almost all the time anyway, and
Firefox is usually running). So this would definitely improve my
situation, as manually (partially) synchronizing extensions and
preferences between profiles is less than pleasant. Maybe Sync would
help, but I haven't tried it yet....
--
Nathan Tuggy [:tuggyne]
nat...@tuggycomputer.com