New historyHandling type of 'launch' for cold start navigations

[bmathwig]

Context: Chrome Status: User Agent Launch Type in PerformanceNavigationTiming

While discussing extending the PerformanceNavigationTiming structure to distinguish between 'warm start' and 'cold start' scenarios, it was mentioned that the NavigationType enumeration maps 1:1 to the historyHandling type in the HTML specification.

In our Explainer for this feature, we have a proposal to include 'launch' as a valid option for historyHandling.

I'm not sure if this is the correct way to map this concept, so I'm looking for your feedback on how to best approach this!

[domenic]

What part of the spec would call the navigation algorithm with this new historyHandling value?

[bmathwig]

In 7.1.1 Creating browsing contexts, step 22 may set the session history entry to 'launch' instead of 'default' if this is the first navigation after the browser process has been created and no other navigation has occurred previously due to the browser already being started.

Does that seem like the right place for it?

[domenic]

I guess that is a reasonable approach to speccing the feature overall. (It probably needs some tweaks, e.g. as written it uses implementation-specific concepts like "browser process" and it sounds like it would only apply to one navigation per session, not to e.g. iframe navigations or other-tab navigations that are also cold starts, but we can figure that out later...)

Now that you've clarified that, I think I'm leaning away from the idea of adding this as a new history handling type. The reason is that in #6315, we're actually planning to break the correspondence, by removing the "entry update" and "reload" history handling behaviors in favor of just two ("push" and "replace"). See more at https://whatpr.org/html/6315/browsing-the-web.html#navigating-across-documents , in particular the green note which explains the future status quo.

The other reason is that, if the plan is for this mode to behave the same as "default" (soon to be renamed "push") everywhere except in navigation timing, then probably it's best to keep the distinction in navigation timing, so that everyone else doesn't have to make sure they always treat them the same.

So overall, I think it makes the most sense for navigation timing to have prose like what you proposed, at the point where it determines whether to set its own value to "launch" vs. "navigate".

If we had a fully rigorous specification which set appropriate user-agent-wide variables to track first vs. later navigations, etc., and we could then thread "launch" through perfectly from "create a new browsing context" into navigation timing, then I would say it's worthwhile to have something separate in the HTML level. But given that we're going to have something "may" based that uses vague, action-at-a-distance concepts anyway, I think it's not necessary to put HTML in the loop.

Does that sound good?

[bmathwig]

Sounds good, thanks Domenic!

[yoavweiss]

@domenic - please keep Navigation Timing in the loop (and in mind) with that refactoring