<html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div>This thread is moving faster than I can reply to during meetings! I'm really looking forward to meeting so we can discuss this as a group.</div><div><br></div><div>Well stated Mike. I agree 100% with that. I think there definitely some "safe" steps we can take to help our users proactively. Then there will be some riskier behaviors, disabling a troublesome addon for example, that the user should have the choice of initiating. These are all subsets of the full Reset. Then we should still offer the complete (and destructive in some minor ways) Reset as an option for users that don't want to take the time to be meticulous and just want to "fix it" with as little input as possible. A nice big button at the top/bottom of FHR for this "full spectrum antibiotic" approach seems like a great place. That would tie all of these user initiated solutions together with all of the useful information FHR can provide.<br></div><div><br></div><div>Matt<br></div><div><br></div><div><br></div><div>On Jul 11, 2013, at 10:49 AM, Mike Connor <mconnor@mozilla.com> wrote:<br></div><div style="color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div><br></div>> I think we have to separate "safe" maintenance steps from destructive ones. I suspect there's a subset of Reset that could be run frequently without ill effect. Of the remainder, I suspect there are ways to clear up common issues (i.e. preserve key customizations like toolbars while nuking localstore.rdf) without users being affected. I'm not sure we could ever entirely rid ourselves of the destructive aspects of Reset Firefox, but that doesn't mean we can't do better than an all or nothing approach.<br>> <br>> -- Mike<br>> <br>> On 2013-07-11 12:17 AM, Jared Wein wrote:<br>>> I don't know how we could perform maintenance every six weeks and achieve anything positive from it if it is not removing user's settings, customization, and/or information. Simply removing/disabling add-ons for users every six weeks isn't something we could live with.<br>>> <br>>> If the maintenance is to fix bugs that have cropped up from older versions, then we can use our pre-existing migration approach for fixing those issues (which already runs every six weeks when a user gets a new version).<br>>> <br>>> In summary, I think maintenance has to be an opt-in process and can't be triggered or run based off of some heuristic or timing interval.<br>>> <br>>> Cheers,<br>>> Jared<br>>> <br>>> ----- Original Message -----<br>>>> From: "Bram Pitoyo" <bram@mozilla.com><br>>>> To: "Tyler Downer" <tdowner@mozilla.com><br>>>> Cc: "Alex Keybl" <akeybl@mozilla.com>, "Ibai Garcia" <igarcia@mozilla.com>, "Madhava Enros" <madhava@mozilla.com>,<br>>>> "Matthew Grimes" <mgrimes@mozilla.com>, "Mike Connor" <mconnor@mozilla.com>, "Cheng Wang" <cww@mozilla.com>, "Asa<br>>>> Dotzler" <asa@mozilla.com>, "David Tenser" <djst@mozilla.com>, "Firefox Dev" <firefox-dev@mozilla.org><br>>>> Sent: Wednesday, July 10, 2013 11:55:06 PM<br>>>> Subject: Re: Reset Firefox -> Repair Firefox<br>>>> <br>>>>> run a set of maintenance on every update […] to always keep the browser at<br>>>>> peak performance<br>>>> This is an interesting idea. In place of a browser that actively<br>>>> monitors performance degradation (which will cause performance<br>>>> degradation in itself), we can just perform a cleanup on every update.<br>>>> Maintenance every six weeks (or several weeks afterwards, if the user<br>>>> updates late) is better than nothing at all, or maintenance when<br>>>> problem happens.<br>>>> <br>>>> The negative side I can foresee is that this process will add to the<br>>>> total install or maybe even firstrun time. But I don’t think that it’s<br>>>> a major deterrent, as long as the installation file itself is fast to<br>>>> download, and the browser runs fast any other time other than<br>>>> firstrun.<br>>>> <br>>>> On Thu, Jul 11, 2013 at 11:55 AM, Tyler Downer <tdowner@mozilla.com> wrote:<br>>>>> Replies inline<br>>>>> <br>>>>> <br>>>>> Tyler Downer<br>>>>> User Advocate for All Things Firefoxy<br>>>>> <br>>>>> On 7/10/13 4:00 PM, Cheng Wang wrote:<br>>>>>> <br>>>>>> <br>>>>>> Ibai Garcia wrote:<br>>>>>>> This conversation is really exciting.<br>>>>>>> <br>>>>>>> If we Firefox can detect there's an issue, what's the need to trying to<br>>>>>>> repair itself on Update and at intervals?<br>>>>>> <br>>>>>> Detection has costs (and sometimes very high ones). If Firefox is<br>>>>>> constantly self-monitoring, that may mean slower video playback or higher<br>>>>>> memory usage, so we have to be very careful to pick things that are<br>>>>>> lightweight for this category. It can't be "everything". The benefit of<br>>>>>> doing user-initiated actions is that users expect to be without their<br>>>>>> browser during the brief diagnostic/repair process.<br>>>>> We also shouldn't wait until there is a problem to run repairs. If we can<br>>>>> run a set of maintenance on every update (RStrong, yes, you are current in<br>>>>> your interpretation of update :) to always keep the browser at peak<br>>>>> performance, it's better than waiting until the browser perf has degraded<br>>>>> to<br>>>>> the point where we need to run the same maintenance.<br>>>>> <br>>>>>>> If Firefox can detect that something is not working, can we just simply<br>>>>>>> run the process of measuring "health of the browser" at regular<br>>>>>>> intervals and if something is not as expected, then we proactively offer<br>>>>>>> to fix it.<br>>>>>> <br>>>>>> There's an analogue to this: updates. We used periodically monitor for<br>>>>>> updates and if you weren't up to date, we offered to update you. People<br>>>>>> didn't like that because they could be in the middle of something<br>>>>>> important<br>>>>>> when the dreaded "please restart your browser" window popped up and back<br>>>>>> then updates were even less frequent. I'm not even sure doing it on update<br>>>>>> is right but at least that's only every few weeks. More frequent could be<br>>>>>> worse.<br>>>>> Agreed. And for some stuff that won't change a user's experience (except<br>>>>> make stuff faster) we should do it automatically with no prompts.<br>>>>> <br>>>>>>> Then there's the question of what represents an issue, and as in the<br>>>>>>> previous comment, if by repairing things we could trigger a downgraded<br>>>>>>> experience we may need to be cautious on communicating what's happening<br>>>>>>> behind the scenes and not "force" a "repair".<br>>>>>>> <br>>>>>> I think Tyler means downgrading the browser (like from 22 to 21). We<br>>>>>> should be careful that we don't break things but if the thing we break is<br>>>>>> users moving from a recent and supported Firefox version to an older one,<br>>>>>> it's not a big concern.<br>>>>> Exactly, thanks Cheng.<br>>>>> <br>>>>>>> Ibai<br>>>>>>> <br>>>>>>> <br>>>>>>> On Jul 10, 2013, at 1:06 PM, Tyler Downer <tdowner@mozilla.com<br>>>>>>> <mailto:tdowner@mozilla.com>> wrote:<br>>>>>>> <br>>>>>>>> Just to tack onto this discussion:<br>>>>>>>> <br>>>>>>>> For step 1, I see three different places that Firefox should try to<br>>>>>>>> repair itself:<br>>>>>>>> <br>>>>>>>> * On Update<br>>>>>>>> * At regular intervals<br>>>>>>>> * When Firefox detects issues<br>>>>>>>> <br>>>>>>>> Any ideas for things Firefox can do at these points would be awesome.<br>>>>>>>> We have ideas like Matt said, along with some other ideas (cleaning up<br>>>>>>>> no-longer used preferences, etc.)<br>>>>>>>> <br>>>>>>>>> Would this result in a degradation of the "upgrade -> downgrade"<br>>>>>>>> experience? At a glance, "remove >old addon-compat overrides" sounds<br>>>>>>>> like it might result in the newly downgraded version not working >the<br>>>>>>>> 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<br>>>>>>>> isn't supported.<br>>>>>>>> Those users that do downgrade will mostly be more advanced users, or<br>>>>>>>> will be visiting SUMO for more help. Since downgrading isn't built<br>>>>>>>> into the product or supported, I'm fine with it being a bit more<br>>>>>>>> difficult.<br>>>>>>>> <br>>>>>>>> Tyler Downer<br>>>>>>>> User Advocate for All Things Firefoxy<br>>>>>>>> On 7/9/13 3:03 PM, Matthew Grimes wrote:<br>>>>>>>>> Hey Madhava,<br>>>>>>>>> <br>>>>>>>>> Thanks for looping us in. We have been quite involved in the Fx Reset<br>>>>>>>>> conversations over the last few months. It is an extremely exciting<br>>>>>>>>> project and one that I think we are not leveraging nearly to its full<br>>>>>>>>> potential. Some this came from an awesome conversation I had with Asa<br>>>>>>>>> a few months back. We see three basic layers in our fight for<br>>>>>>>>> Recoverability:<br>>>>>>>>> <br>>>>>>>>> 1. Proactively protect our users so that they don't experience<br>>>>>>>>> problems in the first place (or fix the problem before the user<br>>>>>>>>> notices)<br>>>>>>>>> 2. If we fail at #1, ensure that we are empowering our users to self<br>>>>>>>>> recover in the least painful and destructive ways possible.<br>>>>>>>>> 3. If the user fails at self recovery (it will happen no matter how<br>>>>>>>>> hard we work), point the user to a friendly place to seek 1 on 1<br>>>>>>>>> help aka SUMO<br>>>>>>>>> <br>>>>>>>>> For our 1st layer of Recoverability, we could perhaps run a check on<br>>>>>>>>> places.sqlite after each update to ensure we haven't decimated the<br>>>>>>>>> user's bookmarks, perform periodic database cleanups, remove old<br>>>>>>>>> addon-compat overrides, monitor ballooning cache sizes, etc. All of<br>>>>>>>>> these things can and should be done without user initiation. There<br>>>>>>>>> are quite a few other suggestions that we've tossed around as well,<br>>>>>>>>> but I don't want to get too deep into the weeds here. We also lack<br>>>>>>>>> the Engineering chops to know what is and is not possible, so I'd<br>>>>>>>>> LOVE LOVE to discuss in further detail with some of the big brains on<br>>>>>>>>> this thread.<br>>>>>>>>> <br>>>>>>>>> In the 2nd layer of Recoverability, what we had envisioned was having<br>>>>>>>>> FHR present a very strategic list of suggested fixes based on the<br>>>>>>>>> data we extract. This list may offer suggestions like disabling a<br>>>>>>>>> particular add-on that causes slowness, crashes, excessive memory use<br>>>>>>>>> etc or alerts the user if select about:config values have been<br>>>>>>>>> changed to non-default values. Some of these items are currently<br>>>>>>>>> covered in FX Reset, but we'd offer them as more surgical fixes. I'd<br>>>>>>>>> even like to see information from plugincheck<br>>>>>>>>> <http://www.mozilla.org/en-US/plugincheck/>, as well as out of date<br>>>>>>>>> graphics card drivers with links to updates if that were possible.<br>>>>>>>>> This would give the user the option to take a very methodical and<br>>>>>>>>> surgical approach to recovering. In the event that these steps fail,<br>>>>>>>>> or for users that don't care to be surgical, we could also offer the<br>>>>>>>>> "Full" Firefox Reset. We are working on making the Fx Reset less<br>>>>>>>>> destructive <https://bugzilla.mozilla.org/show_bug.cgi?id=833943>,<br>>>>>>>>> but by nature a reset results in loss of customization. For some<br>>>>>>>>> users the time savings may be worth the mild discomfort. Others may<br>>>>>>>>> still prefer the meticulous approach.<br>>>>>>>>> <br>>>>>>>>> Finally, if the user simply cannot self recover we would direct them<br>>>>>>>>> to SUMO where they can get the 1 on 1 support they would need.<br>>>>>>>>> <br>>>>>>>>> I think that was a very roundabout way of answering your question.<br>>>>>>>>> Let me know if you'd like to set something up to discuss in greater<br>>>>>>>>> detail. We are always happy to help!<br>>>>>>>>> <br>>>>>>>>> Matt<br>>>>>>>>> <br>>>>>>>>> <br>>>>>>>>> ------------------------------------------------------------------------<br>>>>>>>>> *From: *"Madhava Enros" <madhava@mozilla.com><br>>>>>>>>> *To: *"Mike Connor" <mconnor@mozilla.com><br>>>>>>>>> *Cc: *"Alex Keybl" <akeybl@mozilla.com>, "Asa Dotzler"<br>>>>>>>>> <asa@mozilla.com>, "Firefox Dev" <firefox-dev@mozilla.org>, "Matthew<br>>>>>>>>> Grimes" <mgrimes@mozilla.com>, tdowner@mozilla.com<br>>>>>>>>> *Sent: *Monday, July 8, 2013 1:53:03 PM<br>>>>>>>>> *Subject: *Re: Reset Firefox -> Repair Firefox<br>>>>>>>>> <br>>>>>>>>> For sure - as soon as you have a button for users to press that is<br>>>>>>>>> essentially the "Work Properly" button, the question presents itself:<br>>>>>>>>> why do we wait for them to press it.<br>>>>>>>>> <br>>>>>>>>> Matt Grimes and Tyler Downer have been thinking on this subject; I<br>>>>>>>>> know they mentioned ideas for future "milder" versions of Firefox<br>>>>>>>>> Reset that we could be running periodically automatically.<br>>>>>>>>> <br>>>>>>>>> Madhava<br>>>>>>>>> <br>>>>>>>>> --<br>>>>>>>>> Madhava Enros<br>>>>>>>>> Firefox User Experience<br>>>>>>>>> mozilla.org/firefox <http://mozilla.org/firefox><br>>>>>>>>> <br>>>>>>>>> On Monday, July 8, 2013 at 4:42 PM, Mike Connor wrote:<br>>>>>>>>> <br>>>>>>>>> On 2013-07-08 3:04 PM, Alex Keybl wrote:<br>>>>>>>>> <br>>>>>>>>> I think we'd be better off calling this feature "Repair<br>>>>>>>>> Firefox".<br>>>>>>>>> <br>>>>>>>>> The only issues I see here is that Repair Firefox implies a<br>>>>>>>>> guaranteed solution, while a reset is just a tool that may<br>>>>>>>>> help. Also, users may wonder why we don't always attempt a<br>>>>>>>>> repair on launch every time, if there's no negative<br>>>>>>>>> consequences.<br>>>>>>>>> <br>>>>>>>>> If we're going to do something like this we should really find a<br>>>>>>>>> way of<br>>>>>>>>> a) doing this incrementally and in-process and b) based on<br>>>>>>>>> detection of<br>>>>>>>>> problematic states. That would leave the manual "big reset button"<br>>>>>>>>> to<br>>>>>>>>> cover the cases we can't automatically detect/fix. (And we should<br>>>>>>>>> track<br>>>>>>>>> those resets, maybe in FHR, to get a handle on how much it's still<br>>>>>>>>> necessary.)<br>>>>>>>>> <br>>>>>>>>> -- Mike<br>>>>>>>>> <br>>>>>>>>> <br>>>>>>>>> _______________________________________________<br>>>>>>>>> firefox-dev mailing list<br>>>>>>>>> firefox-dev@mozilla.org <mailto:firefox-dev@mozilla.org><br>>>>>>>>> https://mail.mozilla.org/listinfo/firefox-dev<br>>>>>>>>> <br>>>>>>>>> <br>>>>>>>>> <br>>>>> _______________________________________________<br>>>>> firefox-dev mailing list<br>>>>> firefox-dev@mozilla.org<br>>>>> https://mail.mozilla.org/listinfo/firefox-dev<br>>>> _______________________________________________<br>>>> firefox-dev mailing list<br>>>> firefox-dev@mozilla.org<br>>>> https://mail.mozilla.org/listinfo/firefox-dev<br>>>> <br>> <br><div><br></div></div><div><br></div></div></body></html>