I'm trying to cross-check this new event against my bootstrap proposal from 2y ago.
In my proposal I suggested the following stages:
1. First Paint
2. First Confluent Paint
3. Visually Completed Paint
4. Chrome Interactive
5. Fully Loaded
The intention for this model was to intertwine two sides (engine vs app) in a two-way communication allowing the app to wait for the engine, but also for the engine to optimize against app bootstrapping.
The event you're adding here seems to be either (4) or (5), and I think it would be useful to further specify which one it is.
I'll describe the difference:
- Chrome Interactive gets fired when the UI of the app is fully usable, and it is expected that tasks initialized by that event will not affect the sense of the visual settlement or basic interactivity by the user. User can click on each button, scroll, and so on.
A good example of what might go here is a pre-load of a data needed for common, but user-activated operations. For example address bar history may be loaded now, because visually the UI is complete, event observers are attached to the address bar, and if the user will click on it, the drop-down will be waiting for that load.
Since we expect the user to click on the addressbar most of the time, we may eagerly trigger this data fetch now, and in result when the user activates the address bar, the history will be available sooner.
- Fully Loaded is an event intended to inform us that the startup has completely settled. This is the moment where we expect that without further user interaction and until some scheduled timers kick off, no activity is going to happen. No further loads after this point, no further modules to auto-initialize.
This stage is mostly useful for the engine to perform initial GC/CC, for integration tests to measure memory, time-to-fully-loaded, potentially cache some parts of the memory to speed up load next time and maybe submit telemetry.