<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 7/10/2013 1:06 PM, Tyler Downer
wrote:<br>
</div>
<blockquote cite="mid:51DDBEAB.4050802@mozilla.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Just to tack onto this discussion:<br>
<br>
For step 1, I see three different places that Firefox should try
to repair itself:<br>
<ul>
<li>On Update <br>
</li>
</ul>
</div>
</blockquote>
This should be at application version change since profiles that
didn't perform the update (e.g. users of a system that didn't
perform the update and users with more than one profile) have no way
of knowing that an update has happened though they can tell that the
application version has changed. If you want to limit this to only
the times that the application version increases that is also
detectable with this method.<br>
<br>
<blockquote cite="mid:51DDBEAB.4050802@mozilla.com" type="cite">
<div class="moz-cite-prefix">
<ul>
<li> </li>
<li>At regular intervals</li>
<li>When Firefox detects issues</li>
</ul>
Any ideas for things Firefox can do at these points would be
awesome. We have ideas like Matt said, along with some other
ideas (cleaning up no-longer used preferences, etc.)<br>
<br>
>Would this result in a degradation of the "upgrade ->
downgrade" experience? At a glance, "remove >old addon-compat
overrides" sounds like it might result in the newly downgraded
version not working >the same way after downgrade as it did
before the original upgrade. <br>
<br>
Downgrading isn't the main focus for two reasons:<br>
Old versions of Firefox aren't supported or secure, so
downgrading isn't supported.<br>
Those users that do downgrade will mostly be more advanced
users, or will be visiting SUMO for more help. Since downgrading
isn't built into the product or supported, I'm fine with it
being a bit more difficult. <br>
<br>
<pre class="moz-signature" cols="72">Tyler Downer
User Advocate for All Things Firefoxy</pre>
On 7/9/13 3:03 PM, Matthew Grimes wrote:<br>
</div>
<blockquote
cite="mid:1814085531.397584.1373407421772.JavaMail.zimbra@mozilla.com"
type="cite">
<div style="font-family: times new roman, new york, times,
serif; font-size: 12pt; color: #000000">
<div>Hey Madhava,<br>
</div>
<div><br>
</div>
<div>Thanks for looping us in. We have been quite involved in
the Fx Reset conversations over the last few months. It is
an extremely exciting project and one that I think we are
not leveraging nearly to its full potential. Some this came
from an awesome conversation I had with Asa a few months
back. We see three basic layers in our fight for
Recoverability:<br>
</div>
<div>
<ol>
<li>Proactively protect our users so that they don't
experience problems in the first place (or fix the
problem before the user notices)<br>
</li>
<li>If we fail at #1, ensure that we are empowering our
users to self recover in the least painful and
destructive ways possible.<br>
</li>
<li>If the user fails at self recovery (it will happen no
matter how hard we work), point the user to a friendly
place to seek 1 on 1 help aka SUMO<br>
</li>
</ol>
For our 1st layer of Recoverability, we could perhaps run a
check on places.sqlite after each update to ensure we
haven't decimated the user's bookmarks, perform periodic
database cleanups, remove old addon-compat overrides,
monitor ballooning cache sizes, etc. All of these things can
and should be done without user initiation. There are quite
a few other suggestions that we've tossed around as well,
but I don't want to get too deep into the weeds here. We
also lack the Engineering chops to know what is and is not
possible, so I'd LOVE LOVE to discuss in further detail with
some of the big brains on this thread. <br>
</div>
<div><br>
</div>
<div>In the 2nd layer of Recoverability, what we had
envisioned was having FHR present a very strategic list of
suggested fixes based on the data we extract. This list may
offer suggestions like disabling a particular add-on that
causes slowness, crashes, excessive memory use etc or alerts
the user if select <a moz-do-not-send="true"
class="moz-txt-link-freetext" href="about:config">about:config</a>
values have been changed to non-default values. Some of
these items are currently covered in FX Reset, but we'd
offer them as more surgical fixes. I'd even like to see
information from <a moz-do-not-send="true"
href="http://www.mozilla.org/en-US/plugincheck/"
data-mce-href="http://www.mozilla.org/en-US/plugincheck/">plugincheck</a>,
as well as out of date graphics card drivers with links to
updates if that were possible. This would give the user the
option to take a very methodical and surgical approach to
recovering. In the event that these steps fail, or for users
that don't care to be surgical, we could also offer the
"Full" Firefox Reset. We are working on making the <a
moz-do-not-send="true"
href="https://bugzilla.mozilla.org/show_bug.cgi?id=833943"
data-mce-href="https://bugzilla.mozilla.org/show_bug.cgi?id=833943">Fx
Reset less destructive</a>, but by nature a reset results
in loss of customization. For some users the time savings
may be worth the mild discomfort. Others may still prefer
the meticulous approach. <br>
</div>
<div><br>
</div>
<div>Finally, if the user simply cannot self recover we would
direct them to SUMO where they can get the 1 on 1 support
they would need.<br>
</div>
<div><br>
</div>
<div>I think that was a very roundabout way of answering your
question. Let me know if you'd like to set something up to
discuss in greater detail. We are always happy to help!<br>
</div>
<div><br>
</div>
<div>Matt<br>
</div>
<div><br>
</div>
<hr id="zwchr">
<div
style="color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"
data-mce-style="color: #000; font-weight: normal;
font-style: normal; text-decoration: none; font-family:
Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Madhava
Enros" <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:madhava@mozilla.com"><madhava@mozilla.com></a><br>
<b>To: </b>"Mike Connor" <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:mconnor@mozilla.com"><mconnor@mozilla.com></a><br>
<b>Cc: </b>"Alex Keybl" <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:akeybl@mozilla.com"><akeybl@mozilla.com></a>,
"Asa Dotzler" <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:asa@mozilla.com"><asa@mozilla.com></a>,
"Firefox Dev" <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:firefox-dev@mozilla.org"><firefox-dev@mozilla.org></a>,
"Matthew Grimes" <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:mgrimes@mozilla.com"><mgrimes@mozilla.com></a>,
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:tdowner@mozilla.com">tdowner@mozilla.com</a><br>
<b>Sent: </b>Monday, July 8, 2013 1:53:03 PM<br>
<b>Subject: </b>Re: Reset Firefox -> Repair Firefox<br>
<div><br>
</div>
<div><span style="font-size: 15px;"
data-mce-style="font-size: 15px;">For sure - as soon as
you have a button for users to press that is essentially
the "Work Properly" button, the question presents
itself: why do we wait for them to press it.</span></div>
<div><span style="font-size: 15px;"
data-mce-style="font-size: 15px;"><br>
</span></div>
<div><span style="font-size: 15px;"
data-mce-style="font-size: 15px;">Matt Grimes and Tyler
Downer have been thinking on this subject; I know they
mentioned ideas for future "milder" versions of Firefox
Reset that we could be running periodically
automatically.</span></div>
<div><span style="font-size: 15px;"
data-mce-style="font-size: 15px;"><br>
</span></div>
<div><span style="font-size: 15px;"
data-mce-style="font-size: 15px;">Madhava</span></div>
<div>
<div><br>
</div>
<div>-- </div>
<div>Madhava Enros</div>
<div>Firefox User Experience</div>
<div>mozilla.org/firefox</div>
<div><br>
</div>
</div>
<p style="color: #A0A0A8;" data-mce-style="color: #a0a0a8;">On
Monday, July 8, 2013 at 4:42 PM, Mike Connor wrote:</p>
<blockquote
style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"
data-mce-style="border-left-style: solid; border-width:
1px; margin-left: 0px; padding-left: 10px;">
<div>
<div>
<div>On 2013-07-08 3:04 PM, Alex Keybl wrote:</div>
<blockquote>
<div>
<blockquote>
<div>I think we'd be better off calling this
feature "Repair Firefox".</div>
</blockquote>
<div>The only issues I see here is that Repair
Firefox implies a guaranteed solution, while a
reset is just a tool that may help. Also, users
may wonder why we don't always attempt a repair
on launch every time, if there's no negative
consequences.</div>
</div>
</blockquote>
<div>If we're going to do something like this we
should really find a way of</div>
<div>a) doing this incrementally and in-process and b)
based on detection of</div>
<div>problematic states. That would leave the manual
"big reset button" to</div>
<div>cover the cases we can't automatically
detect/fix. (And we should track</div>
<div>those resets, maybe in FHR, to get a handle on
how much it's still</div>
<div>necessary.)</div>
<div><br>
</div>
<div>-- Mike</div>
<div><br>
</div>
<div><br>
</div>
<div>_______________________________________________</div>
<div>firefox-dev mailing list</div>
<div><a moz-do-not-send="true"
href="mailto:firefox-dev@mozilla.org"
target="_blank"
data-mce-href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
</div>
<div><a moz-do-not-send="true"
href="https://mail.mozilla.org/listinfo/firefox-dev"
target="_blank"
data-mce-href="https://mail.mozilla.org/listinfo/firefox-dev">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div><br>
</div>
</div>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
firefox-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/firefox-dev">https://mail.mozilla.org/listinfo/firefox-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>