<div dir="ltr"><div><div><div><div>(Let me just get this to photon-dev to get wider input...)<br><br></div>So there are two features related to this discussion and fortunately (unfortunately?) both are currently being planned in Taipei.<br><br></div>1) Onboarding: We will have an opportunity here to "auto-refresh" profiles for the returning users (to be defined as users falls into row 46 of the master planning doc). There aren't a lot of activities yet so I am not sure what we are really going to do there, yet.<br><br></div>2) The "Optimize Firefox" button in Performance panel in the new Preferences. This is <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1354473">https://bugzilla.mozilla.org/show_bug.cgi?id=1354473</a> and is being actively planned on. So far we already know this is *not* an auto-refreseh, i.e. the user has to click on that "optimize" button, and we already know we want to preserve add-ons (WebExtensions only, or WebExtensions + Test Pilot add-ons only) compared to what "Refresh Firefox" currently does.<br><br></div>For (2) my approach is to look at the old meta <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=851364">https://bugzilla.mozilla.org/show_bug.cgi?id=851364</a> and get the follow up done, and rename it to "Optimize Firefox". We can surely keep the feature separate, and call the feature that move original set of data "refresh" and more data with "optimize", but regardless I would imagine they will be sharing the most of the reset code.<br><div><br></div><div>Let's discuss this more in the context of (2).<br></div><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 6, 2017 at 7:14 PM, Tim Guan-tin Chien <span dir="ltr"><<a href="mailto:timdream@mozilla.com" target="_blank">timdream@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Cindy, Tina, Philipp are the people that should take this into consideration. This is mostly a product call.  </div><div><br></div><div>Shouldn't this just reach photon-dev?</div><div><br></div><div><br></div><div>Tim</div><div class="HOEnZb"><div class="h5"><div><br><div class="gmail_quote"><div>On Thu, Apr 6, 2017 at 6:49 PM Gijs Kruitbosch <<a href="mailto:gkruitbosch@mozilla.com" target="_blank">gkruitbosch@mozilla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="m_-398168650965923833gmail_msg">
<br class="m_-398168650965923833gmail_msg">
I'm glad folks are working on some of the onboarding flows and Photon<br class="m_-398168650965923833gmail_msg">
initial/returning user experiences. I just wanted to write a quick email<br class="m_-398168650965923833gmail_msg">
about the auto-refresh bugs that recently saw some more activity (deps<br class="m_-398168650965923833gmail_msg">
of <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1268708" rel="noreferrer" class="m_-398168650965923833gmail_msg" target="_blank">https://bugzilla.mozilla.org/<wbr>show_bug.cgi?id=1268708</a> ). I assume Matt<br class="m_-398168650965923833gmail_msg">
or I will end up reviewing these patches and wanted to clarify some<br class="m_-398168650965923833gmail_msg">
things before the patches get written, to make sure we're on the same<br class="m_-398168650965923833gmail_msg">
page and reduce churn.<br class="m_-398168650965923833gmail_msg">
<br class="m_-398168650965923833gmail_msg">
The main reason I'm emailing is the discrepancy that I see (and I could<br class="m_-398168650965923833gmail_msg">
be seeing that mistakenly!) between my understanding the refresh<br class="m_-398168650965923833gmail_msg">
internals, and the aims of the Photon launch and auto-refresh work.<br class="m_-398168650965923833gmail_msg">
<br class="m_-398168650965923833gmail_msg">
Technically speaking, refresh creates a completely new profile, and then<br class="m_-398168650965923833gmail_msg">
copies a limited subset of data from the old profile into the new profile.<br class="m_-398168650965923833gmail_msg">
<br class="m_-398168650965923833gmail_msg">
What the Photon and auto-refresh want is "get rid of all the<br class="m_-398168650965923833gmail_msg">
(potentially) broken things" in the user's profile. Make things shiny<br class="m_-398168650965923833gmail_msg">
and fast (and not outdated-looking/behaving).<br class="m_-398168650965923833gmail_msg">
<br class="m_-398168650965923833gmail_msg">
The discrepancy here is how much stuff we do end up getting rid of. We<br class="m_-398168650965923833gmail_msg">
can obviously add to the limited set of data we currently copy in from<br class="m_-398168650965923833gmail_msg">
the old profile, but there is a "long tail" of items that users might<br class="m_-398168650965923833gmail_msg">
rely on and that we don't currently copy, like:<br class="m_-398168650965923833gmail_msg">
- add-ons. This is <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1017919" rel="noreferrer" class="m_-398168650965923833gmail_msg" target="_blank">https://bugzilla.mozilla.org/<wbr>show_bug.cgi?id=1017919</a><br class="m_-398168650965923833gmail_msg">
, though even with that we wouldn't migrate separately stored add-on<br class="m_-398168650965923833gmail_msg">
data or settings;<br class="m_-398168650965923833gmail_msg">
- settings. We don't copy any main user preferences right now;<br class="m_-398168650965923833gmail_msg">
- permissions granted to websites, including storage-related ones;<br class="m_-398168650965923833gmail_msg">
- local storage / sqlite / appcache website data (so some saved state<br class="m_-398168650965923833gmail_msg">
from existing websites/apps will disappear);<br class="m_-398168650965923833gmail_msg">
- CDMs for DRM'd media (ie netflix and friends) display (so video might<br class="m_-398168650965923833gmail_msg">
not play while we download them again);<br class="m_-398168650965923833gmail_msg">
- content preferences (zoom levels, character sets to use, etc., stored<br class="m_-398168650965923833gmail_msg">
in a separate sqlite db compared to normal settings/prefs);<br class="m_-398168650965923833gmail_msg">
- some security data like the certificate cache, certificate overrides,<br class="m_-398168650965923833gmail_msg">
revocation data, and the HSTS ("use https for this site") cache, meaning<br class="m_-398168650965923833gmail_msg">
some (badly configured) websites might no longer load;<br class="m_-398168650965923833gmail_msg">
- ... probably other stuff that I've forgotten by now.<br class="m_-398168650965923833gmail_msg">
<br class="m_-398168650965923833gmail_msg">
<br class="m_-398168650965923833gmail_msg">
Arguably, if users choose to use refresh themselves, some level of<br class="m_-398168650965923833gmail_msg">
cleanup is expected - we make very explicit in the UI what things will<br class="m_-398168650965923833gmail_msg">
be kept and what things won't be kept, and where to find a back-up. The<br class="m_-398168650965923833gmail_msg">
reason we don't keep everything is that if users refresh Firefox some of<br class="m_-398168650965923833gmail_msg">
that stuff is probably broken (e.g. the website storage or permissions<br class="m_-398168650965923833gmail_msg">
databases could be corrupted) and we should get rid of it.<br class="m_-398168650965923833gmail_msg">
<br class="m_-398168650965923833gmail_msg">
What I'm concerned about is doing this automatically without user<br class="m_-398168650965923833gmail_msg">
intervention. Then the (automatic, no interaction) deletion of all that<br class="m_-398168650965923833gmail_msg">
data/settings info might cause dataloss and disruption to users. I think<br class="m_-398168650965923833gmail_msg">
we should be very careful when implementing that. This is compounded by<br class="m_-398168650965923833gmail_msg">
us not being perfect at establishing when users last used Firefox, cf.<br class="m_-398168650965923833gmail_msg">
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1054947" rel="noreferrer" class="m_-398168650965923833gmail_msg" target="_blank">https://bugzilla.mozilla.org/<wbr>show_bug.cgi?id=1054947</a> .<br class="m_-398168650965923833gmail_msg">
<br class="m_-398168650965923833gmail_msg">
As a result, I would like to make sure we consider if there are subsets<br class="m_-398168650965923833gmail_msg">
of the data I mentioned above that we do also need to add to refresh,<br class="m_-398168650965923833gmail_msg">
maybe only in the auto-refresh case (perhaps we can copy databases only<br class="m_-398168650965923833gmail_msg">
if they're not corrupted, or we can copy a subset of user settings, or...).<br class="m_-398168650965923833gmail_msg">
<br class="m_-398168650965923833gmail_msg">
I also think we should do careful gradual testing "in the real world" of<br class="m_-398168650965923833gmail_msg">
the auto-refresh feature (with funnelcakes, or with <a href="http://usertesting.com" rel="noreferrer" class="m_-398168650965923833gmail_msg" target="_blank">usertesting.com</a>, or<br class="m_-398168650965923833gmail_msg">
with a gradual roll-out, and/or with post-refresh surveys) before we<br class="m_-398168650965923833gmail_msg">
release it. I think we should make sure it is behind a pref so we can<br class="m_-398168650965923833gmail_msg">
control when/where we roll it out.<br class="m_-398168650965923833gmail_msg">
<br class="m_-398168650965923833gmail_msg">
I'm happy to talk more about this either via email or IRC/slack or by<br class="m_-398168650965923833gmail_msg">
setting up a meeting - I just figured email was the easiest way to get<br class="m_-398168650965923833gmail_msg">
this ball rolling.<br class="m_-398168650965923833gmail_msg">
<br class="m_-398168650965923833gmail_msg">
Thanks for reading,<br class="m_-398168650965923833gmail_msg">
Gijs<br class="m_-398168650965923833gmail_msg">
<br class="m_-398168650965923833gmail_msg">
</blockquote></div></div></div></div><span class="HOEnZb"><font color="#888888"><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature">(Apologies — sent from mobile)</div></font></span></blockquote></div><br></div>