Add sanity checking to browser.sessionstore.max_resumed_crashes?
Angie Byron (Drupal)
I had posted a "bug report" at https://bugzilla.mozilla.org/show_bug.cgi?id=501995
about the fact that Firefox doesn't prompt me to restore my browsing
session the first time, and Simon pointed out that this behaviour is
by design, decided over at https://bugzilla.mozilla.org/show_bug.cgi?id=448976#c10.
He suggested I post here on the newsgroup to talk about this decision.
While I agree that this behaviour makes good sense for the majority of
users, for me it is quite frustrating. In a typical browsing session I
have > 20 windows and > 100 tabs open (I know, I know...) so without
fail, a single Firefox crash quickly turns into a double Firefox
crash, at which point I finally get the prompt where I can start a new
session.
Simon informed me of the browser.sessionstore.max_resumed_crashes
variable, which I've since changed from 2 to 1, so I'm good now.
However, it seems to me that it might make sense to add some basic
sanity checking to this value. If you have > ~20 browser instances
open, you probably do NOT want them all to come on at once, because
your Internet connection becomes instantly saturated and... boom.
Firefox Crash II: The Sequel.
So, just a thought... what about adding something like a
browser.sessionstore.max_browser_instances or something which, if
exceeded, will override the decision of max_resumed_crashes and prompt
regardless? I'm all about choosing sensible defaults for 99% of users,
but the default behaviour for us 1% is really, really nasty.
Thanks for your consideration. :)
-Angie
Mike Beltzner
I agree that our current check for "should we restore the session" is
a little simplistic at the moment; I think there's probably much we
could do to improve it. Thanks for filing the bug.
Heuristics I see as useful are:
- if a crash happens twice in rapid succession, be sure to bring up
the restoration panel
- bring up the restoration panel if the user is holding down some
key on startup
- add an option to the crash reporter which brings up the
restoration panel
I'm not sure that large-tab-load cases are best suited for always
bringing up the restoration panel. I'd rather solve the other issues
at hand there, like ensuring that we can reload your tabs and windows
properly without crashing!
cheers,
mike
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Simon Bünzli
> Heuristics I see as useful are:
>
> - if a crash happens twice in rapid succession, be sure to bring up the
> restoration panel
We already show the Restore page when the browser crashes two or more
times in a row (that's configurable by the max_resumed_crashes pref).
> - bring up the restoration panel if the user is holding down some key
> on startup
There's one key that already does that: the Safe Mode key. And that
one's even quite discoverable. ;-)
> - add an option to the crash reporter which brings up the restoration
> panel
I'd argue that restarting into Safe Mode would be more useful, and you'd
get the desired behavior as a side effect for free.
> I'm not sure that large-tab-load cases are best suited for always
> bringing up the restoration panel.
As long as large tab groups can take minutes to restore (be it because
we try to do everything at once, creating an artificial performance
bottleneck, or be it that we simply can't be more efficient), this might
not be too bad an idea, actually. We already do that for opening e.g.
large bookmark folders, so why not reuse the same prefs
(browser.tabs.warnOnOpen and browser.tabs.maxOpenBeforeWarn) for Session
Restore as well - at least for the crash recovering case?
Cheers,
Simon
Dave Townsend
> Mike Beltzner schrieb am 06.07.09 15:08:
>> Heuristics I see as useful are:
>>
>> - if a crash happens twice in rapid succession, be sure to bring up
>> the restoration panel
>
> We already show the Restore page when the browser crashes two or more
> times in a row (that's configurable by the max_resumed_crashes pref).
>
>> - bring up the restoration panel if the user is holding down some key
>> on startup
>
> There's one key that already does that: the Safe Mode key. And that
> one's even quite discoverable. ;-)
>
>> - add an option to the crash reporter which brings up the restoration
>> panel
>
> I'd argue that restarting into Safe Mode would be more useful, and you'd
> get the desired behavior as a side effect for free.
Worth pointing out I think that the bug
https://bugzilla.mozilla.org/show_bug.cgi?id=347680 is looking at a lot
of this sort of stuff
Michael Kohler
> Mike Beltzner schrieb am 06.07.09 15:08:
>> panel
>
> I'd argue that restarting into Safe Mode would be more useful, and you'd
> get the desired behavior as a side effect for free.
This would be bug 347680 [1].
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=347680
OT: Simon, could you please take a look at the last few comments of that
bug?
Angie Byron
> > - add an option to the crash reporter which brings up the restoration
> > panel
>
> I'd argue that restarting into Safe Mode would be more useful, and you'd
> get the desired behavior as a side effect for free.
As someone who spends her entire life in Firebug, this would actually
*not* be the desired behaviour for me, unless I misunderstand.
The current situation is Firefox crashes, I force quit it, I start it
again and shake my fist at the 20,000 windows that proceed to open, I
roll my eyes and force quit it again, restart it, and then I'm on my
way.
The proposed situation means Firefox crashes, I force quit it, I start
it again, it disables all of my extensions, I quit it again because I
need those extensions, and then restart it once more the normal way.
Basically, the same number of steps.
But the real problem with auto-starting in Safe Mode is I might not
*know* that Safe Mode disables all of my extensions, if I've never
booted into Safe Mode before and have a tendency to go "yeah yeah
whatever" at help text. And I might then spend another hour after
Firefox starts in safe mode doing shiny, happy browsing only to
discover at one point "Oh, crap. I need Firebug. Oh, crap. It's gone!
MARGH! Now I have to restart my browser *again* and I've got all of
this work sitting in a half-finished state!" And then there begins a
long string of cussing that makes my cats look at me funny.
Nope. All I want is to simply be prompted to restart a new, normal
session after force quitting Firefox with tons and tons of tabs
open. :) Adding an extra button there for people who are having a
really bad repeated crashing problem that *requires* safe mode to
continue is fine, but please don't try and "guess" that that's what's
desired, as I forsee it only resulting in frustrated users who can't
figure out where their extensions went.
-Angie
Jennifer Boriss
The problem Angie is describing is not necessarily one of an explicit crash, but also of things grinding to a halt. Maybe one tab is crashing Firefox, but often the combination of many intensive tabs is making it freeze and die slowly. This is when we get our spinning pinwheel of death, and on OSX the Force Quit menu will show that Firefox is "not responding." Though I can often wait a long amount of time for it to begin responding again, this can take fifteen minutes and I (and probably Angie) would rather force quit.
For me, a comic adventure of browser whack-a-mole now begins. I've force-quit or crashed Firefox, and now it will restore my 5,000 tabs in 600 Windows. So, I'm desperately trying to close windows as they reappear. Funnier still is that the Windows first render in a row, and then move to where they were last placed. So now I'm trying to violently close windows before they move out of my cursor's reach.
To enter safe mode automatically I feel would add insult to injury - it's not the addons the user doesn't want, but their horrible tab session.
I've been meaning to bring this issue up for a long time - I'm glad Angie reminded me.
So, what to do? A possibility is, as Angie mentioned, make the default browser.sessionstore.max_resumed_crashes 1. At first thought, this seems like it could be a positive move. Setting this value at two is a bit arbitrary, and of course you're putting users like Angie at twice the pain, twice the mintiness. The drawback of making this value 1 is only that the user might have to click one extra button after crashing. One extra click to me seems vastly less pain than two crashes.
To truly answer the question of if the value should be 1, I'd want to get a sense of how many users benefit from having everything automatically restore after one crash (people who have hit one snag) vs people who want to start over (Angie & myself) or disable some tabs after one crash.
- Boriss
-Angie
Mike Beltzner
> So, what to do? A possibility is, as Angie mentioned, make the
> default browser.sessionstore.max_resumed_crashes 1. At first
> thought, this seems like it could be a positive move. Setting this
> value at two is a bit arbitrary, and of course you're putting users
> like Angie at twice the pain, twice the mintiness. The drawback of
> making this value 1 is only that the user might have to click one
> extra button after crashing. One extra click to me seems vastly
> less pain than two crashes.
This is flawed logic, as it presumes that the needs of the few
outweigh the needs of the many. We, in fact, had this approach in
Firefox 3.0 and Firefox 2.0. The default value was "1".
We changed this explicitly for Firefox 3.5 because the vast majority
of the time the answer to that question is "yes." That's what's best
for users. I'm a little surprised at the idea that since the cost is
just "one click," it's less pain. "One click" comes with cognitive
load, time to figure out which of the buttons you want to press, and
displeasure at not having been returned to where you were before a
crash. It is not without pain, especially when it occurs to a larger
percentage of users.
> To truly answer the question of if the value should be 1, I'd want
> to get a sense of how many users benefit from having everything
> automatically restore after one crash (people who have hit one snag)
> vs people who want to start over (Angie & myself) or disable some
> tabs after one crash.
Again, I think this logic is flawed. We should be more clever about
how we handle a restore in the case where we know such a restoration
would be painful, not change a global default based on some survey
which wouldn't be likely to have statistical power. Smarter systems,
not binary choices, will win the design competition here.
cheers,
mike
Joe Drew
On Jul 10, 2009, at 10:25 PM, Mike Beltzner wrote:
> We should be more clever about how we handle a restore in the case
> where we know such a restoration would be painful
in the mean time, and we should make every restoration completely
effortless in the long term.
Chris Hofmann
sounds interesting. based on something like this?
if (more than 10 tabs and/5 windows opened on last crash)
// restoration will be a circus
then
show more session restore choices
is this kinda what you, angie, and jennifer are all thinking would solve
the problem?
is there a bug on file?
-chofmann
> not change a global default based on some survey which wouldn't be
> likely to have statistical power. Smarter systems, not binary choices,
> will win the design competition here.
>
> cheers,
> mike