(In reply to Gabriele Svelto [:gsvelto] from comment #2)
So the real fix here would involve two things: change
getStartupInfo() to return intervals, not absolute times. And then go through the code and find all instances of
Date.now() - <Date instance> and switch them to
Performance.now() - <DOMHighResTimeStamp instance>. A quick grep reveals there's at least 282 of those.
Yikes, that sounds like a bunch of work. Mike, based on your comments in bug 1601993, do you want to keep the negative numbers internally? As a stopgap, we could just enforce that the values we store and/or use to determine whether to show the bar are positive, so at least people don't get the notification if their startup was really quick?
Intuitively, I don't think the bug here could happen unless startup was relatively quick and the machine clock got adjusted (e.g. by the OS having done an NTP check inbetween the start of startup and the check here being hit), so I think we should probably at least not show the notification bar in this case... That'd be fairly straightforward to fix, I think?
Though I suppose there's no reason that the adjustment has to be negative, so equally the adjustment could kick us into "oh look, we took 45 seconds to start up" territory just because the NTP clock adjustment moved the clock forward by 43 seconds... and there's no "quick" fix for that.
I guess we could iteratively improve things here by just also storing the highres timestamps on the startup info object, in addition to the Date instance ones, so then we can iteratively switch consumers over to the new stuff? It does look like [the number of calls to
getStartupInfo()](https://searchfox.org/mozilla-central/search?q=getStartupInfo() is actually relatively minimal, so maybe that on its own is not super hard to fix...