FNPRMS fully drawn time does not take into account top sites (M4)

[mcomella]

When the user has tabs or collections, the RecyclerView draws once for "No tabs" and draws again when the tabs arrive. The current reportFullyDrawn implementation does not take this second draw into account and thus is not entirely accurate.

┆Issue is synchronized with this Jira Task

[mcomella]

This behavior may change in #7740 because the RecyclerView takes a long time to inflate.

[hawkinsw]

After investigation today with @MarcLeclair , I believe that this needs to be a very high priority. After a recent change to the application (during the nightly migration), there is a new intent dispatcher that has been inserted into startup. This impacts when the application's first layout traversal happens -- it moves it from after the home fragment is inflated to before the home fragment is created. This means that the Displayed time (upon which we rely for our FNPRMS numbers) will now no longer reflect the time that it takes to inflate the home fragment.

@MarcLeclair and I confirmed this from a theoretical and an empirical perspective. In order to test it empirically, we added a Thread.sleep(5000) in the HomeActivity.onCreate() method and watched that our Displayed time did not skyrocket. We compared that to adding a Thread.sleep(5000) to the GleanMetricsService.setStartupMetrics() method (which executes before the first layout traversal) where that addition did affect the Displayed time by an appropriate amount.

Not only does this reinforce the fact that we need to add reportFullyDrawn and use that for FNPRMs, but it also confirms the investigation into when the Displayed flag.

[mcomella]

I landed #7780 and I believe it already addresses the case hawkinsw is concerned about above #7781 (comment). Addressing this ticket would fix the case where we have open tabs (and thus we redraw the RV again) but that isn't one of our current requirements. Sending this back to triage...

[mcomella]

Visual completeness is strange here: we display an animation to show the async-loaded tabs but we probably don't want to include the animation in our time to visual completeness. Theoretically, we could instrument the first frame of that animation though.

[mcomella]

The PR #8615 landed. Unfortunately, I don't see the consistent regression we expect in the FNPRMS results: it landed on Feb 28 and Feb 29 is 8ms regression while Mar 1 is additional 9ms regression. I wonder if another improvement landed.

[mcomella]

This does not look like it will impact stability nor can it be tested by QA so not requesting QA and can close.