when will navigation FetchEvent.resultingClientId have a reserved client and not an initial about:blank client?

[wanderview]

Previously I thought initial about:blank mainly occurred for iframes. Looking at the spec, though, now I'm not sure.

It seems the initial about:blank document is always created in step 5 here:

https://html.spec.whatwg.org/#creating-a-new-browsing-context

And then its set execution ready in step 7.

It seems this means we should always have an active about:blank document when performing a navigation FetchEvent? Is this right? Or is there something in the spec which implies we should create a separate reserved Client for things like top level navigations?

Note, we don't actually create an initial about:blank for things like top level navigations, but I'm trying to expose the clients as defined in the spec. When should the initial about:blank conceptually exist?

[jungkees]

When should the initial about:blank conceptually exist?

The initial about:blank in the spec is created when a browsing context is created as you pointed. This applies to any browsing contexts: top-level, nested, and auxiliary. For top-level navigations within the same browsing context, the initial about:blank client is always replaced by a reserved client (which we decided to not expose to script) as they have different origins.

It seems this means we should always have an active about:blank document when performing a navigation FetchEvent? Is this right?

For the initial navigation, I think that's true. For an iframe and auxiliary window with the same origin to the parent frame, the active about:blank document should be the landing client. For the top-level browsing context, that'd be replaced by a new landing client.

Or is there something in the spec which implies we should create a separate reserved Client for things like top level navigations?

The environment created in https://html.spec.whatwg.org/#process-a-navigate-fetch step 4 is the reserved client for a navigation request. The environment itself should not be exposed to script as we decided, but fetchEvent.resultingClientId should convey either this environment's id or the initial about:blank client's id depending on the cases. I'm planning to spec that in Handle Fetch.

[wanderview]

I think that makes sense. I have to double check how that plays out in my implementation.

[wanderview]

And thanks for the quick answer!

[wanderview]

Looking at my code it seems I got this right after all. Yay for past Ben, but that guy really should have left a comment.

Thanks again for the quick help!