<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">This thread has evolved past what's
reasonably feasible to overview and participate in. Could we move
this brain dump to a separate document that people could more
easily comment and build on? (Tyler, this is my way of saying that
your ideas are awesome and I want to make sure they're not lost in
the vastness of our inboxes!)<br>
<br>
Thanks!<br>
<br>
- David<br>
<br>
On 2013-07-13 00:36, Tyler Downer wrote:<br>
</div>
<blockquote cite="mid:51E084FF.3050807@mozilla.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<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 moz-do-not-send="true" 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>
</blockquote>
<br>
</body>
</html>