<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>This conversation is really exciting.</div><div><br></div><div>If we Firefox can detect there's an issue, what's the need to trying to repair itself on Update and at intervals?</div><div><br></div><div>If Firefox can detect that something is not working, can we just simply run the process of measuring "health of the browser" at regular intervals and if something is not as expected, then we proactively offer to fix it. </div><div><br></div><div>Then there's the question of what represents an issue, and as in the previous comment, if by repairing things we could trigger a downgraded experience we may need to be cautious on communicating what's happening behind the scenes and not "force" a "repair".</div><div><br></div><div>Ibai</div><div><br></div><br><div><div><div>On Jul 10, 2013, at 1:06 PM, Tyler Downer <<a href="mailto:tdowner@mozilla.com">tdowner@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<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>
<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; ">
<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 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="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 class="moz-txt-link-rfc2396E" href="mailto:madhava@mozilla.com"><madhava@mozilla.com></a><br>
<b>To: </b>"Mike Connor" <a class="moz-txt-link-rfc2396E" href="mailto:mconnor@mozilla.com"><mconnor@mozilla.com></a><br>
<b>Cc: </b>"Alex Keybl" <a class="moz-txt-link-rfc2396E" href="mailto:akeybl@mozilla.com"><akeybl@mozilla.com></a>, "Asa
Dotzler" <a class="moz-txt-link-rfc2396E" href="mailto:asa@mozilla.com"><asa@mozilla.com></a>, "Firefox Dev"
<a class="moz-txt-link-rfc2396E" href="mailto:firefox-dev@mozilla.org"><firefox-dev@mozilla.org></a>, "Matthew Grimes"
<a class="moz-txt-link-rfc2396E" href="mailto:mgrimes@mozilla.com"><mgrimes@mozilla.com></a>, <a 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><a href="http://mozilla.org/firefox">mozilla.org/firefox</a></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>
</div>
</blockquote></div><br></div></body></html>