Trigger Refresh Firefox if users don't user Firefox over 60 days. It is mentioned in the flow chart. : https://bug1268708.bmoattachments.org/attachment.cgi?id=8746819
But I think we don't need to refresh Firefox if users don't update Firefox anymore even they don't use Firefox over 60 day. What do you think? Michael.
(In reply to Evan Tseng [:evanxd] from comment #1) > But I think we don't need to refresh Firefox if users don't update Firefox > anymore even they don't use Firefox over 60 day. > > What do you think? Michael. Hi Verdi, Yes, follow Evan's question. We would like to ask the following question based on the flow chart: - Don't need to refresh Firefox if users don't update Firefox anymore even they don't use Firefox over 60 day. What do you think? - For this route: Launch Firefox > No Pending Update > Last used time less than 60 days > No What's New > Home Page, it looks like this is daily usage of Firefox. So if user has set the Home Page to Google, then here, the Home Page is Google not our default one right?  The flow chart attachment 8746819 [details] from bug 1268708
Before doing this auto-refresh work, there is some risk from Bug 1054947 we should think through. That is Firefox would mis-judge a user as a returning user if that user had been using Firefox for over 60 days in a row without closing Firefox. In this case, there could be a chance we accidentally auto-refresh a very active use's profile. More details from an email thread by Gijs as bellow: > Technically speaking, refresh creates a completely new profile, and then copies a limited subset of data from the old profile into the > new profile. > > What the Photon and auto-refresh want is "get rid of all the (potentially) broken things" in the user's profile. Make things shiny and > fast (and not outdated-looking/behaving). > > The discrepancy here is how much stuff we do end up getting rid of. We can obviously add to the limited set of data we currently copy > in from the old profile, but there is a "long tail" of items that users might rely on and that we don't currently copy, like: > - add-ons. This is https://bugzilla.mozilla.org/show_bug.cgi?id=1017919 , though even with that we wouldn't migrate separately stored add-on data or settings; > - settings. We don't copy any main user preferences right now; > - permissions granted to websites, including storage-related ones; > - local storage / sqlite / appcache website data (so some saved state from existing websites/apps will disappear); > - CDMs for DRM'd media (ie netflix and friends) display (so video might not play while we download them again); > - content preferences (zoom levels, character sets to use, etc., stored in a separate sqlite db compared to normal settings/prefs); > - some security data like the certificate cache, certificate overrides, revocation data, and the HSTS ("use https for this site") > cache, meaning some (badly configured) websites might no longer load; > - ... probably other stuff that I've forgotten by now. > > > Arguably, if users choose to use refresh themselves, some level of cleanup is expected - we make very explicit in the UI what things will be kept and what things won't be kept, and where to find a back-up. The reason we don't keep everything is that if users refresh Firefox some of that stuff is probably broken (e.g. the website storage or permissions databases could be corrupted) and we should get rid of it. > > What I'm concerned about is doing this automatically without user intervention. Then the (automatic, no interaction) deletion of all > that data/settings info might cause dataloss and disruption to users. I think we should be very careful when implementing that. This > is compounded by us not being perfect at establishing when users last used Firefox, cf. https://bugzilla.mozilla.org/show_bug.> cgi?id=1054947 . > > As a result, I would like to make sure we consider if there are subsets of the data I mentioned above that we do also need to add to > refresh, maybe only in the auto-refresh case (perhaps we can copy databases only if they're not corrupted, or we can copy a subset of > user settings, or...). > > I also think we should do careful gradual testing "in the real world" of the auto-refresh feature (with funnelcakes, or with usertesting.com, or with a gradual roll-out, and/or with post-refresh surveys) before we release it. I think we should make sure it is behind a pref so we can control when/where we roll it out.
Why would you do this? For some of us, accessibility fixes such as extensions to block strobing and animation, preference changes to block strobing and animation, user styles to block strobing and animation, and so on, are important for our safety.
@Verdi, should we close this bug and just focus on bug 1369255?
(In reply to Peter Dolanjski [:pdol] from comment #6) > @Verdi, should we close this bug and just focus on bug 1369255? Yes I think so.
remove whiteboard tag due to its WONTFIX
Remove myself from the assignee since now it is WONTFIX.