Automatic Session Restore - Improvements [UX]
Michael Kohler
that Firefox starts itself into Safe Mode after [max_resumed_crashes +
2] crashes.
Unfortunately this doesn't solve all our crashes, since Safe Mode
doesn't fix the problem. Because of this we need to improve it. In this
discussion I'd like to hear and discuss some ideas how we can detect
different kind of crashes and how we can differentiate them.
In the other thread a lot of ideas have already come up, but it's good
to discuss them again.
Firefox, AFAIK, crashes mostly in following conditions:
* interaction with content
* addon interacts with content -> currently fixed by starting in SM
* plugin
* plugin interacts with content
* ..
Chris, could you please give us some numbers about crashes and re-post
your ideas what we need to improve?
After we know what we need/want to improve exactly, I'll file a meta-bug
and different follow-up bugs.
Millwood
You've left out an important category of "crash". The user visits a
malware site which starts a pop-up storm. Reboots because he can't
think of anything else to do. Restarts firefox.
(IMHO, that's why the default MUST be to ask what to do on restart).
Mike Beltzner
> I have now finished my patch for bug 347680 which adds the improvement
> that Firefox starts itself into Safe Mode after [max_resumed_crashes +
> 2] crashes.
Do we give the user any indication of why they've started up in Safe
Mode, and what they can do or should do about it?
cheers,
mike
Alex Faaborg
> Mode, and what they can do or should do about it?
We are still working on text, but here is the current draft:
title: Firefox had to Perform a Temporary Factory Reset
subtitle: Firefox is closing unexpectedly. As a precaution your custom
settings, themes and extensions have been temporarily disabled.
If you continue to experience problems, you can make some or all of
these changes permanent:
[ ] Disable all add-ons
[ ] Reset toolbars and controls
[ ] Rest all user preferences to Firefox's defaults
Screen shot with some of the older text is up here: https://bug347680.bugzilla.mozilla.org/attachment.cgi?id=415046
-Alex
On Dec 2, 2009, at 11:11 PM, Mike Beltzner wrote:
> On 12/2/2009 5:29 PM, Michael Kohler wrote:
>> I have now finished my patch for bug 347680 which adds the
>> improvement
>> that Firefox starts itself into Safe Mode after
>> [max_resumed_crashes +
>> 2] crashes.
>
> Do we give the user any indication of why they've started up in Safe
> Mode, and what they can do or should do about it?
>
> cheers,
> mike
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Chris Ilias
Would it be possible to add a link to a support.mozilla.com search for
the signature of the latest crash? The articles we have for specific
crash sigs are getting almost no traffic; and our articles teaching
users how to use about:crashes [1][2] have very low understandability
scores. While we can work on improving the understandability of
accessing/using about:crashes, I think having to learn it is an extra
step to frustrate users who are already frustrated by the crash. Adding
a search link to the 'session restore after crash' page could really
help eliminate the extra steps.
[1]<https://support.mozilla.com/en-US/kb/Firefox+crashes>
[2]<https://support.mozilla.com/en-US/kb/Firefox+crashes+when+you+open+it>
chris hofmann
Chris Ilias wrote:
> On 09-12-02 5:29 PM, Michael Kohler wrote:
>> I have now finished my patch for bug 347680 which adds the improvement
>> that Firefox starts itself into Safe Mode after [max_resumed_crashes +
>> 2] crashes.
>>
>> Unfortunately this doesn't solve all our crashes, since Safe Mode
>> doesn't fix the problem. Because of this we need to improve it. In this
>> discussion I'd like to hear and discuss some ideas how we can detect
>> different kind of crashes and how we can differentiate them.
>>
>> In the other thread a lot of ideas have already come up, but it's good
>> to discuss them again.
>>
>> Firefox, AFAIK, crashes mostly in following conditions:
>>
>> * interaction with content
>> * addon interacts with content -> currently fixed by starting in SM
>> * plugin
>> * plugin interacts with content
>> * ..
>>
>> Chris, could you please give us some numbers about crashes and re-post
>> your ideas what we need to improve?
>>
I did a bit of research on this but it may turn out to be a hard
classification problem. Its one of those, "if we are able diagose the
reasons why we crash in certain areas we are 80-90% the way to the fix"
kinds of problems.
Anyway I'm still working on trying to figure out a way to get some
meaningful breakdown of crash areas that might be helpful to:
1- explain to users what the problem might be,
2- allow them some interaction to get back on their feet and up and
running as quickly as possible,
3- or to just perform the actions needed to diagnose and fix the problem
auto-magically for the users.
I talked to Alex a bit yesterday. We all want to get to get to a system
that does #3, but the problem is that is going to be an extremely hard
task. Things like automatically disabling addons after so many
consecutive crashes fall into #3, but most of us looking at crash data
are pretty convinced this will be more of a distraction to users than an
aid, since it solve such a small part of the overall crashing problem.
There might be certain situations where a combination of events could
lead to some refined rules like
- a new recent update to an addon has occured and crash freqency is
increasing
-, or an addon that contains binary components and the addon/firefox
was recently updated
or similar correlations we can draw that might lead to some better
precision and improve the effectiveness of disabling.
another thought is that after we start collecting and analysing more
state info in
https://bugzilla.mozilla.org/show_bug.cgi?id=528657
we might be able to correlate changes in particular states that lead to
possible instability. then we could try some of the auto-magic
corrections, such as:
disabling individual or all addons,
disabiling individual or all pages that were viewed in the last session
from loading
cleaning out possible coruption in components of the profile
--fast load files
--cache
--cookies
--bookmarks
--entire new profile
*
*The automatic action ideas raises some interesting questions. If we
knew a particular url or set of url's would crash the browser because we
haven't shipped a fix yet, would we disable or quarantine the url if it
was found in the user's bookmarks? or would we try to intercept the
loading of these crash pages in the style we do for "safe browsing."
With crash automation testing the number of these kinds click to crash
pages are few, but they do exist.
>> After we know what we need/want to improve exactly, I'll file a meta-bug
>> and different follow-up bugs.
>
> Would it be possible to add a link to a support.mozilla.com search for
> the signature of the latest crash? The articles we have for specific
> crash sigs are getting almost no traffic; and our articles teaching
> users how to use about:crashes [1][2] have very low understandability
> scores. While we can work on improving the understandability of
> accessing/using about:crashes, I think having to learn it is an extra
> step to frustrate users who are already frustrated by the crash.
> Adding a search link to the 'session restore after crash' page could
> really help eliminate the extra steps.
>
> [1]<https://support.mozilla.com/en-US/kb/Firefox+crashes>
> [2]<https://support.mozilla.com/en-US/kb/Firefox+crashes+when+you+open+it>
>
Alex, specifically mentioned in our conversation yesterday that a design
goal is to get people away from needing to go to sumo/support sites for
assistance in diagnosing problems. While this is a worthwhile goal, its
also going to be very hard.
In addition to try and get some metrics around areas of crashes, and
specific actions that could automatically happen to prevent continued or
future crashing out of the crash data, we could also look at trying to
mine similar kinds of data from SUMO kb/forum posts. we could look
through the stuff that has been posted to spot any diagnostic and repair
tasks that could happen automatically.
-chofmann
Alex Faaborg
want to reduce the time threshold between crashes to just a bit beyond
average startup time. At least initially I think a good goal to have
is "users should no longer have to go to sumo to learn what safe mode
is if Firefox won't launch."
From the user's perspective they might not even see 4 sequential
crashes, it will just look like one somewhat longer startup time
followed by Firefox explaining that it had to take some extra measures
to be able to open.
-Alex
On Dec 4, 2009, at 10:45 AM, chris hofmann wrote:
>
>
> Chris Ilias wrote:
>> On 09-12-02 5:29 PM, Michael Kohler wrote:
>>> I have now finished my patch for bug 347680 which adds the
>>> improvement
>>> that Firefox starts itself into Safe Mode after
>>> [max_resumed_crashes +
>>> 2] crashes.
>>>
>>> Unfortunately this doesn't solve all our crashes, since Safe Mode
>>> doesn't fix the problem. Because of this we need to improve it. In
>>> this
>>> discussion I'd like to hear and discuss some ideas how we can detect
>>> different kind of crashes and how we can differentiate them.
>>>
>>> In the other thread a lot of ideas have already come up, but it's
>>> good
>>> to discuss them again.
>>>
>>> Firefox, AFAIK, crashes mostly in following conditions:
>>>
>>> * interaction with content
>>> * addon interacts with content -> currently fixed by starting in SM
>>> * plugin
>>> * plugin interacts with content
>>> * ..
>>>
>>> Chris, could you please give us some numbers about crashes and re-
>>> post
>>> your ideas what we need to improve?
>>>
>
>>> After we know what we need/want to improve exactly, I'll file a
>>> meta-bug
>>> and different follow-up bugs.
>>
>> Would it be possible to add a link to a support.mozilla.com search
>> for the signature of the latest crash? The articles we have for
>> specific crash sigs are getting almost no traffic; and our articles
>> teaching users how to use about:crashes [1][2] have very low
>> understandability scores. While we can work on improving the
>> understandability of accessing/using about:crashes, I think having
>> to learn it is an extra step to frustrate users who are already
>> frustrated by the crash. Adding a search link to the 'session
>> restore after crash' page could really help eliminate the extra
>> steps.
>>
>> [1]<https://support.mozilla.com/en-US/kb/Firefox+crashes>
>> [2]<https://support.mozilla.com/en-US/kb/Firefox+crashes+when+you+open+it
>> >
>
Michael Kohler
> For the decision to try to launch into safe mode, I think we might want
> to reduce the time threshold between crashes to just a bit beyond
> average startup time. At least initially I think a good goal to have is
> "users should no longer have to go to sumo to learn what safe mode is if
> Firefox won't launch."
I disagree since an addon can crash Firefox when interacting with
content. So the user needs to click on "Restore" to provoke a sebsequent
crash. If I should have misunderstood you, could you please explain that
again?