+++ This bug was initially created as a clone of Bug #1015619 +++ Some context: - Bug 848460 reduced this from 60 seconds to 50 and then 45 seconds - Bug 1015619 reduced it to 40 seconds - Bug 1298945 made it so that we only show the slow startup notification in old profiles where a reset is likely to help - The first paint taking >30 seconds used to affect 6% of users (bug 848460 comment 9), today it's 5.55%

It's a bit unfortunate that our SIMPLE_MEASURES_FIRSTPAINT probe maxes out at 30 seconds, since we thus don't know anything the breakdown of users above that threshold. It would be nice to know how many extra users are going to see this, to understand the impact. In any case, 30 seconds is pretty poor, and I'm not aware of any negative fallout from our previous conservative reductions, as noted in comment 0. The one concern that comes to mind is that we don't want to nag users on slow hardware that's struggling to run Firefox... But 30s still feels reasonably high (considering that data and where it's already been at), and bug 1298945 should mitigate this indirectly, since resetting Firefox should result in a new profile / and this timestamp.

(Oh, and it's also a little unfortunate that the histogram evolution of this probe doesn't show any improvement from Release39 to Release54. Hopefully the recent Photon/Quantum work will show results!)

Pushed by dgottwald@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/8827ebefe677 Reduce browser.slowStartup.timeThreshold to 30 seconds. r=dolske

I have reproduced this bug with Nightly 56.0a1 (2017-07-07) on Windows 7, 64 Bit! This bug's fix is verified with latest Beta! Build ID : 20170810180547 User Agent : Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0