850710 - Don't poll for startup info

Status: RESOLVED WONTFIX

(Firefox Health Report Graveyard :: Client: Desktop, defect, P2)

Description

[Gregory Szorc [:gps]]

I'm mass filing large ticket items from FHR's performance review: https://wiki.mozilla.org/Performance/FHR. This bug is for the first item:

5. Polling for startup timestamps If one of the startup milestones (e.g. session-restore) hasn't completed by the time FHR is initialized on startup, FHR polls every 5 seconds for up to 5 minutes to try to obtain the missing timestamp. Couldn't this timestamp be obtained at the end of the session or by registering a listener for the last startup event of interest?

Comment 1

[Richard Newman [:rnewman]]

Do we have some measurements for how many of the startup milestones are outside the FHR startup delay?

If the answer is "basically none", then we should WONTFIX this.

If, say, 10% of our users have FHR polling for two minutes while their browser starts, then sure, we should fix it.

Comment 2

[Mike Connor [:mconnor]]

Well, it'll be 100% of users who have an about:healthreport tab restored.  Hard to measure that.  We also know there are a lot of pathological startup cases out there, and we shouldn't exacerbate them.

That said, there's no reason I can think of to not fix this sooner rather than later, because it's fairly trivial to do this right (just create an observer for the last notification in the series if we hit this condition).  I'm not sure why we chose to do it this way, but it seems like an unnecessarily poor approach.

Comment 3

[Richard Newman [:rnewman]]

(In reply to Mike Connor [:mconnor] from comment #2)

> I'm not sure why we chose to do it this way, but it seems like an
> unnecessarily poor approach.

According to Bug 833612, we were having observer ordering issues, so I imagine Greg opted for KISS.

Comment 4

[Gregory Szorc [:gps]]

(In reply to Richard Newman [:rnewman] from comment #3)
> (In reply to Mike Connor [:mconnor] from comment #2)
> 
> > I'm not sure why we chose to do it this way, but it seems like an
> > unnecessarily poor approach.
> 
> According to Bug 833612, we were having observer ordering issues, so I
> imagine Greg opted for KISS.

Yup. We had to resort to polling because the requested info wasn't always available at the time it was supposed to be. Perhaps we should have the startup timeline send out a notification when it is updated? Or, at least we should allow subscribers to startup timeline events that are guaranteed to fire *after* the timeline is modified.

Comment 5

[Alessio Placitelli [:Dexter]]

FHR is going away per bug 1209088, wontfix.