(@ux-team, ui-r?) Need feedback on "bug 347680: Add Safe Mode option to Session Restore dialogue"
Michael Kohler
I'm working on bug 347680 [1]. I'd like to read some feedback about my
thoughts that I posted on the mozilla wiki:
https://wiki.mozilla.org/User:MichaelKohler/SafeModeOption
I'm wondering if this is even wanted how I'd like to do it, so I'd like
to have ui-r+ on it..
Feel free to ask questions if something is not clear.
Alex Faaborg
sound right on, particularly this part:
> I think that a normal user would be very confused about this, since
> he/she might not even know Safe Mode.
Since the user has just launched into safe mode, should we check
"disable all add ons" by default? (to represent the current status,
and to reduce the number of steps)?
Here is some background information for everyone else on what we are
thinking about changing:
Currently the process is:
-The user notices undesirable symptoms (like "firefox won't start").
-The user has to seek out the solution on their own (go to a support
form, learn about safe mode, follow process).
Proposed approach:
-Firefox detects what is happening (notices that it crashed repeatedly
and before displaying about:sessionrestore)
-Firefox automatically takes the logical course of action (launches
into safe mode).
So for instance in the new approach the user doesn't even have to know
what safe mode is before using it to get Firefox working again.
-Alex
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Jennifer Boriss
what safe mode is before using it to get Firefox working again.
Not making the user look up safe mode when it's needed is all well and good, but we should probably still:
1. Let the user know what has happened (they've entered safemode)
2. Tell them what safemode is
3. Let them exit safemode if they want
This could be done in just a few lines in the about:safemode page, perhaps with a link to more information about safemode. The case I worry about is the user not knowing they are in safemode, noticing their themes & settings are not working, and then trying unsuccessfully to troubleshoot those individual items.
Alex Faaborg
> 2. Tell them what safemode is
> 3. Let them exit safemode if they want
I agree, but I was thinking that instead of branding it with a name we
would just say what steps were taken: "All of your extensions were
disabled." In this case to "exit" they would need to uncheck "disable
all extensions", or later manually re-enable them, which hopefully
will give them a sense of which one is causing Firefox to have problems.
Here is a pretty old mockup that needs to be updated but shows the
overall flow of things going horribly horribly wrong for the user:
https://bug347680.bugzilla.mozilla.org/attachment.cgi?id=336775
The first two recovery conditions are now complete.
-Alex
Alex Faaborg
recovery (of which automatically disabling extensions is just one
component):
https://wiki.mozilla.org/Firefox/Projects/Automatic_Recovery
-Alex
Alex Faaborg
> that tests which addon causes the problems and disables it and
> enables the other ones.
That would be absolutely awesome, and definitely lined up with the
overall goal of Firefox does all the work! :)
This is perhaps way out of scope for any initial changes, but overall
it would be nice if in the future we had a second process which we
could use for things like providing feedback to the user while a
recovery operation like this is going on, silently preparing updates
in the background so there isn't any start up time cost, etc.
> Alex: Will you create a new mockup or is the old one enough for now?
Old one should be good enough for the safe mode failure case if we
can't detect the particular crashing addon (with the edits of removing
the bookmark option, and checking disable addons by default). If we
are able to isolate which add-ons are causing crashes, I can get you a
new interface for that.
I haven't really given much thought to how we should explain to the
user that their profile is corrupted yet, need to give that some
thought.
-Alex
On Aug 21, 2009, at 4:56 PM, Michael Kohler wrote:
> What should we do if the user still wants to use his addons or
> themes or whatever causes the crashes? Do they have to find out
> which addon it is by themself?
>
> I thought about filling a follow-up bug for creating an algorithm
> that tests which addon causes the problems and disables it and
> enables the other ones. This would mean that we need to restart the
> browser multiple times, but IMO this would be a great feature. It
> may even be possible that we would find a more efficient algorithm
> so we don't need to restart after disabling one addon. But I guess
> we don't need to discuss about the algorithm itself for now, just
> about the general idea.
>
> Further I will fill a follow-up bug for restarting using a new
> profile when crashing while going into Safe Mode. This would be the
> last step of Alex' mockup.
>
> Alex: Will you create a new mockup or is the old one enough for now?
>
>
> Please feel free to ask if you should have some questions since my
> English skills are not *that* good.
>
> (Couldn't post this answer to my original response because I wrote
> this using my mobile phone. I'm sorry.)
Michael Kohler
I have now done some work on this bug. Now I stand before a big
decision. The current situation is:
Firefox has crashed once more than specified in
browser.sessionstore.max_resumed_crashes and the about:sessionrestore
page is shown. Now the browser crashes again and should start in Safe
Mode. Do we either want to:
- restart Firefox, check if it needs to load in Safe Mode when
about:sessionrestore is loading and if it needs to, restart again
- or already test if it needs to load in Safe Mode (means recentCrashes
> max_resumed_crashes + 1) when it's startup up (this would mean in
nsAppRunner [1])
The first solution would be way easier to do. But the second one is
probably better because it needs one startup less. Unfortunately I'd not
have any clue how to test the condition written above..
Please ask if you have further questions or it's not explained that good ;)
Sincerely,
Michael
[1]
http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp
Alex Faaborg
I'll follow up in the bug as well, but I'm thinking probably the
second option. Viewing the session restore page already means 2
quickly sequential crashes, followed by loading about:session restore.
If Firefox has to crash 4 times in sequence (instead of 3) before we
load in safe mode, the user probably wont be getting too much visual
feedback, since we are looking at roughly startup time * 4 before they
see something.
That said, if implementing this on 4 crashes is so much easier than 3
that it is the difference between getting the feature landed or having
the bug remain open, then let's go for 4 and bring it down to 3 in a
follow up :)
-Alex
Alex Faaborg
> detect addons that break Firefox
I have no idea, any crash reporter folks around?
On Nov 16, 2009, at 1:49 AM, Michael Kohler wrote:
> Thanks for the feedback. Since I am not that good in programming C++
> I'd rather do 4 startups and file a followup bug. :) Another
> question: I heard something about improving the crash reporter so it
> can detect addons that break Firefox. Is that correct or shall I
> file a followup bug for adding an option to troubleshoot crashhappy
> addons to about:safemode?
>
>
> -----Original Message-----
> From: Alex Faaborg
> Sent: 11/16/2009 8:52:12 AM
> To: Michael Kohler
> Cc: dev-apps...@lists.mozilla.org
> Subject: Re: (@ux-team, ui-r?) Need feedback on "bug 347680: Add
> Safe Mode option to Session Restore dialogue"
chris hofmann
This all sounds way to complex.
People crash for a variety of reasons, but the main two are
1) they hit some page with content, or some network condition, that
tickles a gecko bug and crashes the browser.
2) the got updated with an addon or plugin or external component that is
incompatible with firefox and this incompatibility causes the crash.
If session restore can figure out the condition that's causing the
crash, and isolate it to an addon, then we should throw users into safe
mode. If we can't, then we should just offer safe mode every time we
do session restore.
If session restore can figure out if its a page load that triggers the
crash then we ought to offer the ability not load all pages or or a
specific page as a way out of continued crashing. ---
oh wait, we do the later now....
we should treat the disabling of all addons or selected addons just like
we treat the disabling of all pages or selected pages...
I don' know about crash reporter detecting addons or plugins that break
firefox, but there a few bugs around about blocking addons, and plugins,
and other components https://bugzilla.mozilla.org/show_bug.cgi?id=524904
and there are some bugs about trying to get whatever information we have
about compatibilty problems in the hands of users when we know at least
a little bit, or a lot, about the problem.
https://bugzilla.mozilla.org/show_bug.cgi?id=523427
-chofmann
Michael Kohler
>
> This all sounds way to complex.
I agree.
> If session restore can figure out the condition that's causing the
> crash, and isolate it to an addon, then we should throw users into safe
> mode. If we can't, then we should just offer safe mode every time we do
> session restore.
What about a pref that is set by the user and causes crashes? When we
start in SM we avoid that factor from the beginning and the user doesn't
have to click on "Restart in Safe Mode" or a similar button.
> oh wait, we do the later now....
> we should treat the disabling of all addons or selected addons just like
> we treat the disabling of all pages or selected pages...
I don't understand that right, I guess. Does this mean we should just
restart a new session after entering Safe Mode? This is probably not
what the user wants!
> I don' know about crash reporter detecting addons or plugins that break
> firefox, but there a few bugs around about blocking addons, and plugins,
> and other components https://bugzilla.mozilla.org/show_bug.cgi?id=524904
>
> and there are some bugs about trying to get whatever information we have
> about compatibilty problems in the hands of users when we know at least
> a little bit, or a lot, about the problem.
> https://bugzilla.mozilla.org/show_bug.cgi?id=523427
This could be a follow up bug. Alex, what do you think?
Michael Kohler
>
I agree.
> If session restore can figure out the condition that's causing the
> crash, and isolate it to an addon, then we should throw users into safe
> mode. If we can't, then we should just offer safe mode every time we do
> session restore.
What about a pref that is set by the user and causes crashes? When we
start in SM we avoid that factor from the beginning and the user doesn't
have to click on "Restart in Safe Mode" or a similar button.
> oh wait, we do the later now....
> we should treat the disabling of all addons or selected addons just like
> we treat the disabling of all pages or selected pages...
I don't understand that right, I guess. Does this mean we should just
restart a new session after entering Safe Mode? This is probably not
what the user wants!
> I don' know about crash reporter detecting addons or plugins that break
> firefox, but there a few bugs around about blocking addons, and plugins,
> and other components https://bugzilla.mozilla.org/show_bug.cgi?id=524904
>
> and there are some bugs about trying to get whatever information we have
> about compatibilty problems in the hands of users when we know at least
> a little bit, or a lot, about the problem.
> https://bugzilla.mozilla.org/show_bug.cgi?id=523427
This could be a follow up bug. Alex, what do you think?
chris hofmann
Michael Kohler wrote:
> On 11/16/2009 04:43 PM, chris hofmann wrote:
>>
>> This all sounds way to complex.
>
> I agree.
>
>> If session restore can figure out the condition that's causing the
>> crash, and isolate it to an addon, then we should throw users into safe
>> mode. If we can't, then we should just offer safe mode every time we do
>> session restore.
>
> What about a pref that is set by the user and causes crashes? When we
> start in SM we avoid that factor from the beginning and the user
> doesn't have to click on "Restart in Safe Mode" or a similar button.
>
>> oh wait, we do the later now....
>> we should treat the disabling of all addons or selected addons just like
>> we treat the disabling of all pages or selected pages...
>
> I don't understand that right, I guess. Does this mean we should just
> restart a new session after entering Safe Mode? This is probably not
> what the user wants!
>
no. just starting in safe mode and disabling *all* addons isn't ever
the right decision if the crash that the user sees is a crash that
results: 1) from web content, 2) an incompatible plugin, 3) plugin
interaction with web content, 4) incompatible interaction some other
external program like an anti-virus package.
starting in safe mode also shuts down *all* addons, when in reality its
probably only a few or maybe a single addon that is causing the
problem. safe mode applies a nuclear fix in a situation where that fix
may be one of many things that is needed to solve the problem. it
should be part of the option we might show to users that says "try
everything possible to keep this damn thing from crashing." that option
starts in safe mode, and a completly new session with no pages loaded
from the previous crashing session. It might even start in a new
profile to boot!
short of this nuclear option, we should give the user the option in
session restore to restart with all pages, or just selected pages, and
we should give the option to restart with all addons, or just selected
addons.
-chofmann
>> I don' know about crash reporter detecting addons or plugins that break
>> firefox, but there a few bugs around about blocking addons, and plugins,
>> and other components https://bugzilla.mozilla.org/show_bug.cgi?id=524904
>>
>> and there are some bugs about trying to get whatever information we have
>> about compatibilty problems in the hands of users when we know at least
>> a little bit, or a lot, about the problem.
>> https://bugzilla.mozilla.org/show_bug.cgi?id=523427
>
Michael Kohler
>>> oh wait, we do the later now....
>>> we should treat the disabling of all addons or selected addons just like
>>> we treat the disabling of all pages or selected pages...
>>
>> I don't understand that right, I guess. Does this mean we should just
>> restart a new session after entering Safe Mode? This is probably not
>> what the user wants!
>>
>
> no. just starting in safe mode and disabling *all* addons isn't ever the
> right decision if the crash that the user sees is a crash that results:
> 1) from web content, 2) an incompatible plugin, 3) plugin interaction
> with web content, 4) incompatible interaction some other external
> program like an anti-virus package.
Yes, "if". A lot of crashes are also caused by incompatible addons and
the interaction of addons and websites.
Okay, this could be an additional step. I think we should implement all
those features step-by-step. For now, I'd like to implement just the
restart in SM if Firefox crashed several times (max_resumed_crashes + 2).
> starting in safe mode also shuts down *all* addons, when in reality its
> probably only a few or maybe a single addon that is causing the problem.
> safe mode applies a nuclear fix in a situation where that fix may be one
> of many things that is needed to solve the problem. it should be part of
> the option we might show to users that says "try everything possible to
> keep this damn thing from crashing." that option starts in safe mode,
> and a completly new session with no pages loaded from the previous
> crashing session. It might even start in a new profile to boot!
I'd file a follow up bug that adds an option which would troubleshoot
the addons and report which addon breaks Firefox (and would disable it?)
> short of this nuclear option, we should give the user the option in
> session restore to restart with all pages, or just selected pages, and
> we should give the option to restart with all addons, or just selected
> addons.
We already provide the option to disable pages from being restored. For
the addons see my answer above.
Alex Faaborg
>> have
>> about compatibilty problems in the hands of users when we know at
>> least
>> a little bit, or a lot, about the problem.
>> https://bugzilla.mozilla.org/show_bug.cgi?id=523427
>
> This could be a follow up bug. Alex, what do you think?
yeah, overall we will want the about:safemode page to mostly model the
design of about:session restore:
1) apologize
2) explain what we believe is probably happening
3) give the user tools so they can correct the problem
If we can get as advanced as to inform the user of what specific add-
ons we believe are causing Firefox's complete inability to start up,
that's even better!
-Alex
Alex Faaborg
> crash, and isolate it to an addon, then we should throw users into
> safe mode.
That's the plan, here is an (albeit kind of old) flow chart showing
the general idea:
https://bug347680.bugzilla.mozilla.org/attachment.cgi?id=336775
So instead of the user having to go out and find support documents, or
start to personally debug why Firefox won't launch , and what they
specifically need to do to get Firefox to launch (like learning what
"safe mode" actually is and how to use it), we are trying to use all
available data so that Firefox can actually pick itself up and dust
itself off.
-Alex
On Nov 16, 2009, at 7:43 AM, chris hofmann wrote:
>
> This all sounds way to complex.
>
> People crash for a variety of reasons, but the main two are
>
> 1) they hit some page with content, or some network condition, that
> tickles a gecko bug and crashes the browser.
>
> 2) the got updated with an addon or plugin or external component
> that is incompatible with firefox and this incompatibility causes
> the crash.
>
> If session restore can figure out the condition that's causing the
> crash, and isolate it to an addon, then we should throw users into
> safe mode. If we can't, then we should just offer safe mode every
> time we do session restore.
>
> If session restore can figure out if its a page load that triggers
> the crash then we ought to offer the ability not load all pages or
> or a specific page as a way out of continued crashing. ---
>
> oh wait, we do the later now....
> we should treat the disabling of all addons or selected addons just
> like we treat the disabling of all pages or selected pages...
>
> I don' know about crash reporter detecting addons or plugins that
> break firefox, but there a few bugs around about blocking addons,
> and plugins, and other components https://bugzilla.mozilla.org/show_bug.cgi?id=524904
>
> and there are some bugs about trying to get whatever information we
> have about compatibilty problems in the hands of users when we know
> at least a little bit, or a lot, about the problem. https://bugzilla.mozilla.org/show_bug.cgi?id=523427
>
>
chris hofmann
Alex Faaborg wrote:
>> If session restore can figure out the condition that's causing the
>> crash, and isolate it to an addon, then we should throw users into
>> safe mode.
>
> That's the plan, here is an (albeit kind of old) flow chart showing
> the general idea:
>
> https://bug347680.bugzilla.mozilla.org/attachment.cgi?id=336775
>
> So instead of the user having to go out and find support documents, or
> start to personally debug why Firefox won't launch , and what they
> specifically need to do to get Firefox to launch (like learning what
> "safe mode" actually is and how to use it), we are trying to use all
> available data so that Firefox can actually pick itself up and dust
> itself off.
>
The problem is that figuring out the condition for the crash is a very
hard problem. there are roughly 20,000-30,000 unique kinds of crashes,
of which we only have diagnosed about 100 or so and classified them into
the crash cause.
When session restore runs it doesn't have access to information about
which one of the 20k-30k reasons that might have caused the crash, or if
any of the 100 or so solutions we might have, or even a few simple
solutions might be applied to help stop the crash.
looking at your flow diagram here is one of the common problems it
doesn't solve.
crash is caused by a bug in processing content on a web page.
the following flow then might start.
-auto restart with no session restore
-firefox crashes again on the page loaded in the last session
-auto restart with session restore
-user picks to restart again with all the default settings of previous
pages loaded
-firefox crashes again
-firefox restarts in safemode (addons disabled)
-firefox crashes again when loading the crashy page.
now we have disable addons but still not solved the crash.
here is another common scenario that we have seen.
anti-virus package updates.
firefox crashes because of incompatiblity problem
auto restart with no session restore
firefox crashes due to anti-virus incompat
firefox restarts with session restore
firefox crashes due to anti-virus incompat
firefox restarts in safe mode (addons disabled)
firefox crashes due to anti-virus incompat
now we have disable addons but still not solved the crash.
here is another scenario
firefox or a single addon updates creating some kind of incompatibitly
firefox crashes
auto restart with no session restore
firefox crashes again due to compat problem with the single addon
firefox restarts with session retore
firefox crashes again due to compat problem with the single addon
firefox restarts in safe mode.
ahhhhhh, no crash! ;-)
but, I now have no addons.
I want my 2,3,4,5 or more addons back.
what should I do?
These are not outlier senarios. these are the most common cases that
we should be trying to solve for. How can we reduce the number
of crashes and restarts in these scenario's. How can we get the
user back on their feet in these frequent repeated crash scenario's?
Your right it would much better UX, and be great to have
"firefox pick itself up and dust its self off"
but the problem is that firefox doesn't know exactly what the problem is,
so firefox can't categorize the problem and pick the right solution.
some use interaction might be require to solve the problem
some education might be needed to aid in that user interaction.
that's the state of the art where we are right now. to ignore this
creates the circular crash scenarios I described above ending up
not fixing the crash or diabling things that don't need to be disabled.
-chofmann
>>>> C++ I'd rather do 4 startups and file a followup bug. :) Another
John Wilcock
>
> here is another scenario
>
> firefox or a single addon updates creating some kind of incompatibitly
> firefox crashes
> auto restart with no session restore
> firefox crashes again due to compat problem with the single addon
> firefox restarts with session retore
> firefox crashes again due to compat problem with the single addon
> firefox restarts in safe mode.
> ahhhhhh, no crash! ;-)
>
> but, I now have no addons. I want my 2,3,4,5 or more addons back.
> what should I do?
For the case when an addon has updated, does Firefox have access to a
history of addon installations/updates? If so, it ought to be possible
for it to disable, or display UI to suggest that the user should
consider disabling, just the most-recently-installed addon.
Yes, this is only one of many cases, but it is one that I would have
thought to be relatively easy to solve...
--
John
Michael Kohler
I will finish my current version of the about:safemode option in the
next few days. When it get's r+, I will file followup bugs to improve
and advance it. This will be covered in a meta-bug.
Also I'll start a new thread here to get all interesting ideas together,
how we could improve it (for example the detection of different kind of
crashes).
-- Michael
Alex Faaborg
> "firefox pick itself up and dust its self off"
>
> but the problem is that firefox doesn't know exactly what the
> problem is,
> so firefox can't categorize the problem and pick the right solution.
I guess the overall question is should we launch into temporary safe
mode as a precautionary measure, even if we don't really know that
this will solve the specific problem. In the event that a crash is
being caused by something external to Firefox and outside of its
control (like anti-virus software), safe mode is going to be useless.
> there are roughly 20,000-30,000 unique kinds of crashes, of which we
> only have diagnosed about 100 or so and classified them into the
> crash cause.
Do we have any sense of what percent are caused by issues inside of
Firefox's control (a web page, plug-in, add-on, pref, etc.) and what
percent are caused by issues outside of Firefox's control (anti virus
software, corrupted file system, third party malware, bad RAM?).
It feels like even if the split is 50/50 automatically launching into
safe mode after 4 sequential crashes does more good than harm. Having
all your customizations temporarily disabled isn't ideal, but it
obviously beats having a browser that won't even launch.
The other issue to consider is that if an external issue is preventing
Firefox from opening, the user might not even get to see the page
where we tell them we have performed a temporary factory reset,
depending on how long the timeout is for sequential crashes. So with
a 50/50 spread we don't end up doing something useless half of the
time (because we can't get that far :)
Speaking of, Michael: how much time can pass between crashes with the
user still eventually launching into safe mode on the 4th?
-Alex
> auto restart with no session restore
> firefox crashes due to anti-virus incompat
> firefox restarts with session restore
> firefox crashes due to anti-virus incompat
> firefox restarts in safe mode (addons disabled)
> firefox crashes due to anti-virus incompat
>
> now we have disable addons but still not solved the crash.
>
>
> here is another scenario
>
> firefox or a single addon updates creating some kind of incompatibitly
> firefox crashes
> auto restart with no session restore
> firefox crashes again due to compat problem with the single addon
> firefox restarts with session retore
> firefox crashes again due to compat problem with the single addon
> firefox restarts in safe mode.
> ahhhhhh, no crash! ;-)
>
> but, I now have no addons. I want my 2,3,4,5 or more addons back.
> what should I do?
>
Michael Kohler
> Speaking of, Michael: how much time can pass between crashes with the
> user still eventually launching into safe mode on the 4th?
With my patch Firefox creates a temporary file "startSM.tmp" which makes
that Firefox starts in Safe Mode. This file is only deleted after going
into Safe Mode.
This means that it is just the same time as normal crashes are detected.
This means it should be 6 hours (I asked dietrich and he pointed me to
the code, so it should be correct :))
2843 return max_resumed_crashes != -1 &&
2844 (aRecentCrashes > max_resumed_crashes ||
2845 sessionAge && sessionAge >= SIX_HOURS_IN_MS);
This means 6 hours can pass between the last "normal" crash and the
crash that makes Firefox start in Safe Mode.
BTW: I'll upload a new patch version which corrects the String and icon
changes you suggested in the bug in a few minutes.
chris hofmann
Alex Faaborg wrote:
>> Your right it would much better UX, and be great to have
>> "firefox pick itself up and dust its self off"
>>
>> but the problem is that firefox doesn't know exactly what the problem
>> is,
>> so firefox can't categorize the problem and pick the right solution.
>
> I guess the overall question is should we launch into temporary safe
> mode as a precautionary measure, even if we don't really know that
> this will solve the specific problem. In the event that a crash is
> being caused by something external to Firefox and outside of its
> control (like anti-virus software), safe mode is going to be useless.
>
>> there are roughly 20,000-30,000 unique kinds of crashes, of which we
>> only have diagnosed about 100 or so and classified them into the
>> crash cause.
>
> Do we have any sense of what percent are caused by issues inside of
> Firefox's control (a web page, plug-in, add-on, pref, etc.) and what
> percent are caused by issues outside of Firefox's control (anti virus
> software, corrupted file system, third party malware, bad RAM?).
>
we don't have the exact data you are asking for, but it could be mined
out of socorro with a bit of analysis.
we do know that about 20-25% of crashes are caused by flash,
another 5-10% caused by other plugins.
then the other 65-70% needs more probing. that chunk is between
addons
and the battle ground between malware and antivirus packages
firefox front end (user initiated crashes when they find bugs in the UI)
gecko core -- web content induced
gecko core -- backend induced (stuff like garbage collection and other
non-user, non-content)
> It feels like even if the split is 50/50 automatically launching into
> safe mode after 4 sequential crashes does more good than harm.
yes, that is what I suggested earlier. I'm guessing addons is much less
than 50% of the crashing problems, espcially for "stable releases" where
most of our users are running.
> Having all your customizations temporarily disabled isn't ideal, but
> it obviously beats having a browser that won't even launch.
>
this is trade off against trying to get your customizations running
again. thats also a tedious process and an unnesssary one for the most
of crash situations.