<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Gijs and Mike,<br>
Thanks for your replies! :) I appreciate the more technical
knowledge, since I'm kinda shooting in the dark here on what's
technically possible. <br>
<br>
I'm wanting to think outside the box on what we are already doing
and what we could do in the future. I know Firefox reset is
basically a dumb copy and paste of certain data into a new profile
folder. We should leave this functionality in Firefox Reset itself
for the cases when Firefox can't heal itself. But we are wondering
how feasible it is to do maintenance tasks that aren't currently
done in Firefox Reset, that don't cause the loss of user data, and
will make a users experience with Firefox better. Here's a brain
dump of ideas, feel free to ask questions, point fingers, laugh,
etc ;) I have no idea what's possible and not here.<br>
<br>
Please note, this is a brain dump of alot of ideas that Firefox
can use to repair itself. Not everything here has been thought
through all the way, it's more meant to get ideas rolling.<br>
<br>
<b>Speed:</b><b><br>
</b><i>Cleaning up Preferences</i>: Cheng had mentioned that in
the past, the size of a User's pref file would impact startup to a
certain extent. I'm wondering if we shouldn't have Firefox check
the prefs file to remove any deprecated prefs from previous
versions. We could do this once to clear all prefs that have been
deprecated in the versions that are more than 1-2 releases old.
Then, in the future as we deprecate prefs we can continue to just
keep this file clean. This would obviously be run on upgrade, so
it wouldn't be a significant perf hit. <br>
<br>
<br>
<i>Database Cleanups</i>: We may already do this, so apologies if
we do. However, we could do regular database cleanups of the
various databases used in Firefox. We could do this on every 3rd
upgrade for example, or some number that we decide is frequent
enough to keep the database clean and optimized, and not so
frequent that users will notice a different perf hit. This is
where I'd like some technical insights, is this already being
done, if not, is it technically possible and will it provide a
noticeable user benefit? Also, should we do this on a Reset
instead of simply copy and pasting the database?<br>
<br>
<i>Settings that Impact Performance</i>: We could check if a user
has disabled or changed settings that could impact performance
negatively (HWA, turning off certain JS features, disabled Updates
etc.) and ask if the user meant to turn them off, and provide an
easy button to selectively re-enable them. If they did mean to
turn them off we could direct them to SUMO if they turned them off
to fix a certain issue.<br>
<br>
<b>Settings</b>:<br>
<i>Hijacked Settings</i>: Similar to the above, we can also prompt
users who we detect may have had their customization settings
taken over by a malicious / mal-functioning add-on. if the home
page has been changed, third-party toolbars have been installed,
etc. we can prompt the user if they meant to make that change, and
if they didn't, we can revert these settings. We would want an
easy to hit "Don't show this again" for our technical users.<br>
<br>
<i>Settings that Break the browser</i>: There are certain settings
that have the potential to break the browser (Removing the
navigation toolbar, disabling Javascript, etc.). If we detect
these settings have been changed (which in the JS case is more
difficult recently) and haven't been changed back recently, we can
ask the user if they meant to make the change, and if not, revert
it. We would want an easy to hit "Don't show this again" for our
technical users.<br>
<b><br>
</b><b>Firefox is Borked</b>:<br>
<br>
<i>User Refreshes Web Page multiple times</i>: If a user refreshes
a web page X times in 2 minutes we could probably assume the web
page isn't displaying properly. In that case, we could have a
doorhanger that gives the user the option to clear the cache for
that site and reload again.<br>
<br>
<i>User Reinstalls Firefox</i>: Already in a bug report, but if a
user reinstalls over an exising install of Firefox we should
suggest Reset to the user as a part of the re-install process.<br>
<br>
I'm sure there are lots of use cases and user stories here, I just
wanted to kinda set expectations for what I want this to evolve
into.<br>
<br>
<br>
<br>
<pre class="moz-signature" cols="72">Tyler Downer
User Advocate for All Things Firefoxy</pre>
On 7/12/13 8:26 AM, Mike Connor wrote:<br>
</div>
<blockquote
cite="mid:45D50A22-5BF6-49B6-95DF-E96379197D98@mozilla.com"
type="cite">
<pre wrap="">On 2013-07-12, at 4:36 AM, Gijs Kruitbosch <a class="moz-txt-link-rfc2396E" href="mailto:gkruitbosch@mozilla.com"><gkruitbosch@mozilla.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I think there's a misconception of how reset works. Firefox reset is implemented as essentially creating a new profile, and then copying some files over. The only thing I can think of that'd be called a "maintenance" step is that we only copy a limited part of sessionstore for the current windows/tabs, but that's only on Nightly right now. Otherwise a whole bunch of sqlite and other files are simply copied over so the user doesn't lose data (Matt, please correct me if I'm wrong here!).
The major things we *don't* copy right now are add-ons and preferences, which clearly are where some of the problems are (but not all, eg. hardware acceleration-caused rendering issues) as having them reset to the defaults fixes these problems.
If we want an alternative that we can run periodically and will only reset some preferences / remove some add-ons, it'd probably be helpful to hear from Tyler or other people working in support what kind of issues this usually helps for - website rendering issues, default search provider/homepage hijacks, malicious or unwanted add-ons, and/or other things.
So, right now this seems like a magic bullet but that's in part because of how destructive it really is. I don't think we'll be able to harness the "only a subset of this" power until/unless we understand what it is that we're fixing, exactly.
</pre>
</blockquote>
<pre wrap="">
I can't speak for others, but I'm definitely aware of the current implementation details. I don't think it's quite as much of a black box as it might seem, and I believe we can reason somewhat confidently about which aspects will positively impact users, and how we can automate those aspects.
If we can't actually reason about why profile bustage impacts UX, that would indicate we're in a pretty bad state in terms of delivering a quality app. Fortunately, I am pretty sure we collectively know what's up here. (I'm happy to be involved as much as needed, I still have a ton of tribal knowledge bouncing around in my head.)
-- Mike
</pre>
</blockquote>
<br>
</body>
</html>