Story time: After 1 year of trying to convince a friend to move from Chrome to Firefox, I finally succeeded. This person installed and have been enjoying it with no problems. But now, *2 days in*, Firefox popped up a message saying that it's starting up slow. This is an old-ish computer with a regular HD and there's probably not much that can be done to improve it. The button just takes to the generic Reset Firefox article (https://support.mozilla.org/kb/reset-firefox-easily-fix-most-problems) I think we can all agree that a message by Firefox itself saying that it sucks can't be good for retention. And a profile reset in a two-day old profile won't do much to help. Has this message outlived its effectiveness? Can we find a better entry point to Reset Firefox? If anything, the heuristics need to be improved a lot, and this message should only show up for Very Old profiles. But I'd be happy to see it go entirely too.

I think it's important to put in hooks to Reset Firefox where it makes sense, and startup time is one of the key areas that Reset Firefox can fix. Maybe we just need to change how we determine slow startups have been happening. Can we store more start times, and only show this if the start times get much slower over time?

Michael, what are your thoughts on this? Are there other good entry points to Reset Firefox? Would removing this one be ok?

(In reply to :Felipe Gomes (needinfo me!) from comment #2) > Michael, what are your thoughts on this? Are there other good entry points > to Reset Firefox? Would removing this one be ok? There are other good entry point to refresh but like Jared says in comment #1, this is a key thing that refresh can fix. I'd like to keep it if possible but clearly, as you point out, the heuristics need to be improved. I don't know how it works currently but Jared's suggestion seems right - showing the prompt if the start up time for your computer increases over time.

Ok, anyone opposed to disabling (but not removing) the notification as is now, and filing a follow-up bug to code better heuristics and re-enable it?

Would it be too hard to improve the heuristic in the simplest way possible to fix this case (e.g. the suggestion in comment 0) and file a followup for a more comprehensive overhaul of the heuristics?

We can also look at startup time telemetry to know how often users may be seeing this notification. browser.slowStartup.timeThreshold is currently 40s so knowing the proportion of startups longer than 40s would be useful.

(In reply to Matthew N. [:MattN] from comment #6) > We can also look at startup time telemetry to know how often users may be > seeing this notification. browser.slowStartup.timeThreshold is currently 40s > so knowing the proportion of startups longer than 40s would be useful. That still won't really tell us what the problem is that causes the 40s startup, just how many people are going to be seeing these notifications a lot... Thinking about the cases where reset helps with a slow startup: - Getting rid of add-ons can solve some of this - Getting rid of a lot of tabs can solve some of this but I'm having a hard time thinking of anything else in terms of prefs that get reset etc. that would really have a significant impact on startup time. It can solve other issues, like broken SSL connections, or weird behaviour when trying to use the web because of experimental/feature/"one weird trick to make web pages load faster" prefs that users have toggled, but startup time? I find that hard to believe. Semi-busted places tables and stuff like that won't get fixed, we just copy the files over so that problem would persist after a reset. The problem is that the users who use reset and have a lot of tabs are likely to actually want a lot of those tabs, and likewise for the add-ons, at which point the problem will likely return. So in other words, I'm struggling to see a usecase where reset really does help users with slow startup (even if it definitely solves other issues users might have with Firefox). Jared/Verdi, can you clarify in what circumstances we think Reset will permanently fix something about slow startup that wouldn't then "come back" as the user undoes some of the reset?

(In reply to :Gijs Kruitbosch from comment #7) > (In reply to Matthew N. [:MattN] from comment #6) > > We can also look at startup time telemetry to know how often users may be > > seeing this notification. browser.slowStartup.timeThreshold is currently 40s > > so knowing the proportion of startups longer than 40s would be useful. > > That still won't really tell us what the problem is that causes the 40s > startup, just how many people are going to be seeing these notifications a > lot... I brought this up to use a data point to decide whether we need to disable it now instead of fixing it a bit later. If users are rarely getting startup times great than 40s then we don't need to treat this as a widespread problem and take aggressive action by disabling it. > Thinking about the cases where reset helps with a slow startup: > > - Getting rid of add-ons can solve some of this This can help a lot IME > - Getting rid of a lot of tabs can solve some of this > > but I'm having a hard time thinking of anything else in terms of prefs that > get reset etc. that would really have a significant impact on startup time. > It can solve other issues, like broken SSL connections, or weird behaviour > when trying to use the web because of experimental/feature/"one weird trick > to make web pages load faster" prefs that users have toggled, but startup > time? I find that hard to believe. Semi-busted places tables and stuff like > that won't get fixed, we just copy the files over so that problem would > persist after a reset. I think since we don't copy over places.database.lastMaintenance we do end up triggering places maintenance sooner but that would have happened eventually in their old profile. Just copying the files to a new profile actually can help speed up systems with spinning hard drives as it reduces fragmentation on disk. This was shown to be useful years ago with measurements Taras did. I also think that we should probably be doing more maintenance on the Places data at reset time… > The problem is that the users who use reset and have a lot of tabs are > likely to actually want a lot of those tabs, and likewise for the add-ons, > at which point the problem will likely return. So in other words, I'm > struggling to see a usecase where reset really does help users with slow > startup (even if it definitely solves other issues users might have with > Firefox). > > Jared/Verdi, can you clarify in what circumstances we think Reset will > permanently fix something about slow startup that wouldn't then "come back" > as the user undoes some of the reset? I don't think this is the right question to be asking since the users will likely be able to quickly correlate restoring the tabs and re-enabling the add-ons as the cause of the slowdowns. i.e. If Firefox starts really quickly right after a refresh then becomes slow to restore the tabs or later when some add-ons are re-enabled, the user can possibly realize that Firefox itself isn't what's slow, it's only with a lot of tabs or with the add-ons re-enabled. Basically don't think there has to be a permanent technical fix if the user learns that Fx is fast without tabs and add-ons (after the Refresh). If the undo some of the things that make it faster they can reverse that decision once they learn from it.

For me it's specifically about getting rid of add-ons that the user has forgotten about and has no need for anymore, yet they are loaded during startup and make Firefox slower. Secondly, what is the case with internet proxy settings? I believe those would be reset too, and that would cover something like bug 787757.

Isn't there already per-addon slowness detection that should cover it? "This add-on is making Firefox run slow". Or is that disabled?

I'm morphing this bug to implement the suggestion from comment 0, but I really want to push for more action in a followup to not get the feeling of just kicking the can down the road.

Comment on attachment 8786518 [details] Bug 1298945 - Only show Slow Startup notification if profile is 3 months old. https://reviewboard.mozilla.org/r/75436/#review73396 ::: browser/components/nsBrowserGlue.js:847 (Diff revision 1) > if (averageTime > Services.prefs.getIntPref("browser.slowStartup.timeThreshold")) > - this._showSlowStartupNotification(); > + this._calculateProfileAgeInDays().then(this._showSlowStartupNotification, null); > averageTime = 0; > samples = 0; Hmm… so you're clearing the averageTime and samples even if we don't notify the user. I guess that helps us not hit this code path on every startup if the profile isn't old enough but on the other hand we're throwing away data when we don't really need to. Would it be so bad if on the 5th month of usage we showed the notification bar to the user if they are consistently over the 40s threshold? What were you thinking about this?

(In reply to Matthew N. [:MattN] from comment #13) > Comment on attachment 8786518 [details] > Bug 1298945 - Only show Slow Startup if profile is 5 months old. > > https://reviewboard.mozilla.org/r/75436/#review73396 > > ::: browser/components/nsBrowserGlue.js:847 > (Diff revision 1) > > if (averageTime > Services.prefs.getIntPref("browser.slowStartup.timeThreshold")) > > - this._showSlowStartupNotification(); > > + this._calculateProfileAgeInDays().then(this._showSlowStartupNotification, null); > > averageTime = 0; > > samples = 0; > > Hmm… so you're clearing the averageTime and samples even if we don't notify > the user. Yeah but this code is bad and already does that. It basically throws away all data on every 5th measurement and restarts. Now it will be a matter of how reaching the 150 days lines up with the number of measurements. It might notify right away or it might take up 5 restarts to do so. But that's basically the same as increasing the age threshold by 10 days or so. I indeed did this to avoid hitting this code on every startup, and only ever using it for users who get slow startups. By reading the code from ProfileAge.jsm that looks like an expensive operation, specially done during finalUIStartup. I guess that helps us not hit this code path on every startup if > the profile isn't old enough but on the other hand we're throwing away data > when we don't really need to. Would it be so bad if on the 5th month of > usage we showed the notification bar to the user if they are consistently > over the 40s threshold? > > What were you thinking about this? I didn't understand if you had a different suggestion here. My understanding is that this code implements this. (granted, 5 months +/- 0..10 days)

(In reply to :Gijs Kruitbosch from comment #7) > Jared/Verdi, can you clarify in what circumstances we think Reset will > permanently fix something about slow startup that wouldn't then "come back" > as the user undoes some of the reset? I don't have anything to add that Jared and Matt haven't already said on this. (In reply to :Felipe Gomes (needinfo me!) from comment #10) > Isn't there already per-addon slowness detection that should cover it? "This > add-on is making Firefox run slow". Or is that disabled? I get those notifications in Nightly all the time and I never get slow startup warnings so I don't think they necessarily take the place of the slow startup warning. (In reply to :Felipe Gomes (needinfo me!) from comment #11) > I'm morphing this bug to implement the suggestion from comment 0, Is there a reason not to consider the solution in comment 1? If so, why wait 5 months before messaging someone (I don't understand that part)?

(In reply to Verdi [:verdi] from comment #15) > Is there a reason not to consider the solution in comment 1? If so, why wait > 5 months before messaging someone (I don't understand that part)? I'm all for implementing something better like comment 1 and will file a follow-up for that, but I imagine that will take time and be bikesheded a lot, and I want to take immediate action here to remedy the situation until we can have something better. The reason for waiting some period of time is stated in comment 0. Basically, some users have computers in which startup will be helplessly slow. Displaying to a brand-new user a suggestion to reset their profile is not only unhelpful but actually detrimental to retention and the onboarding experience. I'm ok with discussing how long that period should be, but I really believe it should exist.

(In reply to :Felipe Gomes (needinfo me!) from comment #16) > Basically, some users have computers in which startup will be helplessly > slow. Displaying to a brand-new user a suggestion to reset their profile is > not only unhelpful but actually detrimental to retention and the onboarding > experience. > > I'm ok with discussing how long that period should be, but I really believe > it should exist. In that case we can be much more aggressive. Sadly, waiting 2 or 3 weeks will mean the vast majority of new users never have a chance to see this.

Isn't that a good thing? Why should a new user see an offer to reset their profile?

(In reply to :Felipe Gomes (needinfo me!) from comment #18) > Isn't that a good thing? Why should a new user see an offer to reset their > profile? Ah - I meant that it's sad that we've lost most new users in this time frame which is why they won't have a chance of seeing it.

Comment on attachment 8786518 [details] Bug 1298945 - Only show Slow Startup notification if profile is 3 months old. https://reviewboard.mozilla.org/r/75436/#review74244 I don't have a strong opinon on the time period. r=me with the changes below ::: browser/components/nsBrowserGlue.js:858 (Diff revision 1) > + let tmp = {}; > + Cu.import("resource://gre/modules/ProfileAge.jsm", tmp); `let ProfileAge = Cu.import("resource://gre/modules/ProfileAge.jsm", {}).ProfileAge;` is a more natural way to write this IMO. ::: browser/components/nsBrowserGlue.js:864 (Diff revision 1) > + try { > + creationDate = yield profileAge.created; > + resetDate = yield profileAge.reset; > + } catch (ex) {} I would rather we didn't try…catch these so that we get an error in the error console (which I think would fail tests?). As-is we would fallback to behaviour before your change and would have no indication it wasn't working. https://dxr.mozilla.org/mozilla-central/rev/b7f7ae14590aced450bb0b0469dfb38edd2c0ace/toolkit/components/telemetry/TelemetryEnvironment.jsm#1167 seems to not try…catch it

Reduced it to 3 months

Pushed by felipc@gmail.com: https://hg.mozilla.org/integration/autoland/rev/97471e6c4d4c Only show Slow Startup notification if profile is 3 months old. r=MattN

Comment on attachment 8786518 [details] Bug 1298945 - Only show Slow Startup notification if profile is 3 months old. Approval Request Comment [Feature/regressing bug #]: Slow Startup notification [User impact if declined]: Notification telling users to Reset Profile might show up for brand new users, which is unhelpful [Describe test coverage new/current, TreeHerder]: Landed on central [Risks and why]: Minimal, limited to this feature [String/UUID change made/needed]: none

Comment on attachment 8786518 [details] Bug 1298945 - Only show Slow Startup notification if profile is 3 months old. While this problem is annoying and slows things down, it is unclear to me if this is severe enough to warrant uplifting to 50. I would prefer to let this bake in Nightly51 for a bit more and on Aurora for any unexpected side effects. Please let this ride 51 train to release.

[bugday-20170125]