Bug 836010 implemeted a slow startup prompt to help users diagnose their performance issues in Firefox. It currently points to https://support.mozilla.org/kb/firefox-takes-long-time-start-up. The first step on this article is to Reset Firefox. In fact, that's really the most reliable way to fix any soft of Firefox performance issues. Having an in-product link to a SUMO article is quite clunky. Users don't want to troubleshoot, they just want their problems fixed. We should call Firefox Reset from the notification, and have a smaller, secondary option to go to SUMO for more detailed troubleshooting.

We can now call Firefox Reset/Refresh through UI tour. Details in bug 1063698. We should update the prompt from Bug 836010 to call Reset/Refresh directly. One question. Do we have instrumentation around the usage of this feature? We're interested in understanding the success rate of this prompt as we start working on other similar projects.

Like most of our promotion of firefox reset, I think this is probably a bad idea. Reset is a stopgap solution because we don't understand the problem any better. It has significant downsides for users who actively use extensions. Also, this startup prompt has terrible decision making: it shows up for all kinds of normal users who don't actually have a slow Firefox; perhaps because they launch Firefox while Windows is still finishing its startup, or other similar reasons. I think we should probably remove this prompt altogether, and certainly not make it more dangerous for users.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #2) > Like most of our promotion of firefox reset, I think this is probably a bad > idea. > > Reset is a stopgap solution because we don't understand the problem any > better. It has significant downsides for users who actively use extensions. > > Also, this startup prompt has terrible decision making: it shows up for all > kinds of normal users who don't actually have a slow Firefox; perhaps > because they launch Firefox while Windows is still finishing its startup, or > other similar reasons. I think we should probably remove this prompt > altogether, and certainly not make it more dangerous for users. Agree with your assessment. We can be much more surgical with Self Heal, which is the long term solution. As a stopgap measure, we're asking people to use reset/refresh. If we continue to promote the stopgap measure, we should make it as easy as possible. Refresh is definitely less destructive than it was in previous iterations. Not sure I agree that the cost still outweighs the benefit in the current form, but I could be convinced otherwise!

(In reply to Benjamin Smedberg [:bsmedberg] from comment #2) > Like most of our promotion of firefox reset, I think this is probably a bad > idea. > > Reset is a stopgap solution because we don't understand the problem any > better. This is bug is now 19 months old. Can we please stop postponing helping users in need because the answer we have at the moment is not the perfect answer? We have a prompt that is in use. The request is to replace the link to an article (that now contains a refresh button) with a refresh button thereby removing a step for the user. This is not dangerous. The feature requires the user to explicitly take action. Nothing happens automatically. This is already in use on our most trafficked page (mozilla.org/firefox/new) along with the support site.

I'm not saying this isn't the perfect answer. I'm saying that in the context of the slow-startup prompt, this answer is actively destructive. That prompt is shown in all sorts of incorrect cases, and resetting is likely to make some users unhappy. It's also likely to cause the same prompt to reoccur, potentially leading to permanent loops of users resetting for no good reason.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #5) > I'm not saying this isn't the perfect answer. I'm saying that in the context > of the slow-startup prompt, this answer is actively destructive. That prompt > is shown in all sorts of incorrect cases, and resetting is likely to make > some users unhappy. It's also likely to cause the same prompt to reoccur, > potentially leading to permanent loops of users resetting for no good reason. Refresh is actually a good answer to a slow starting Firefox. It sounds like the prompt is the problem not the answer. So we should fix how the prompt gets displayed. But that shouldn't block this which I'll reiterate has been sitting here for 19 months now.

I see that prompt pretty much every time I create a new profile. Clearly reset is not the right solution *now*. If you want to fix when the prompt is displayed, please help with that. In the meantime, this bug should not proceed.

I met with Benjamin yesterday and we had a chance to talk this through. There are really two concerns here: 1. Users that don't benefit from a reset might be seeing this prompt. If Benjamin is correct, showing this prompt to a user with a new profile and no addons is a failure. This is just one example of failure, but I'm sure there's more. We can either reopen 836010 or file a new bug. 2. We don't actually have any data to understand what happens AFTER a user uses Reset/Refresh. Every time it was used before it created a new FHR id, so the user was essentially "lost" and we couldn't see the impact of the fix. We can now track users across profile resets (35 or 36?). Benjamin suggests doing a round of investigation to see what the impact of the reset has on usage, performance, etc. to ensure this is the best course of action that we currently have. I'll reach out to John J (cc'd on this bug) to find out how quickly we can get that done. Benjamin: Please let me know if I missed something.

(In reply to Matt Grimes [:Matt_G] from comment #8) > find out how quickly we can get that done. Team is slammed right now, give us ~2 weeks. John

Adding Saptarshi coming out of a growth team meeting.

Hello, In the 1% sample(Release, Firefox) as of 2015-02-16, 28,302 profiles tried using ProfileReset. We kept only those profiles with 3+ sessions before the reset and 3+ sessions after the reset (excluding the day of the reset because we don't know if the session restore time for that day was before or after the reset) This leaves us with 2329 profiles (in the 1% sample) that did a reset and have the minimum amount of data. We keep the 3 restore times before the reset and 3 restore times after the reset. We kept the 3 restores times afer because I wanted the restore times to reflect a reset condition. The more reset times we take post reset the more likely they do not reflect the reset. Comparing the session restore time for profiles with a reset before and after the reset, there was a _decrease_ in session restore time. A percentage decrease of (on avg) 8.7% (95% CI is between 6 - 11 %) per profile.

Thanks for the data. This is great. So we know that there is a decrease in session restore time after a reset. What about other indicators? For example, do we see an increase/decrease in overall usage? We want to look at all the possible ways that Refresh may impact the user before we start promoting it more aggressively.