Editorial: Clarify potential execution environment

[domfarolino]

The spec uses the term "potential execution environment" which I find just slightly confusing because it is not defined anywhere. In practice, I believe this simply refers to a request's reserved client and a navigation params's reserved environment, both handled in https://html.spec.whatwg.org/multipage/browsing-the-web.html#:~:text=If%20request%27s%20reserved%20client%20is%20null%2C%20then. This PR specifically links to these concrete definitions when we reference "potential execution environment" for the first time, to clear up exactly what we mean and shed some light on exactly how long an environment is considered "potential".

---

/webappapis.html ( diff )

---

/webappapis.html ( diff )

[domfarolino]

Aside: The definition of environment's top-level origin supports null values, specifically to support "potential execution environment"s: when we construct a new reserved environment/client in https://html.spec.whatwg.org/multipage/browsing-the-web.html#process-a-navigate-fetch (step 13 > 3 > 4), we don't have a good top-level origin to use so we make it null for top-level navigations. It is null until we finally hit https://html.spec.whatwg.org/multipage/browsing-the-web.html#initialise-the-document-object, where we set the environment's top-level origin to the topLevelOrigin var.

I've checked all of the references of environment > top-level origin and none actually seem to expect the origin to be null, so I imagine it would be an error for usage of this member to ever come across a null origin. This reminds me a lot of how after we call https://html.spec.whatwg.org/multipage/browsers.html#creating-browsing-contexts:set-up-a-window-environment-settings-object, the environment setting's object's window does not have an associated document, even though all of its algorithms reference it. We decided we were OK with that, because we don't call any algorithms before we set the actual document, and we can be sure of this because the gap between ESO set-up and document-assignment is short.

I'm wondering if we can do the same for environment's top-level origin member, or if it is too much of a stretch? The gap between creating a reserved environment/client and setting its top-level origin is much larger than the example above, but anything that references the top-level origin within this gap today is already broken I think, so making an explicit carve-out for "null" top-level origins I don't think helps much, and personally confused the heck out of me when I was trying to figure out how useful this "null" origin would be and why its "lifetime" is different than that of the top-level creation URL. I can't imagine others don't have this confusion, but I'm not totally sure if removing "null" as an allowable value here is the best idea, though I think I slightly prefer it, if we document it. Thoughts?

--- Edit ----

I found that top-level origin is expected to be null for top-level reserved clients in Fetch here, which makes perfect sense. I wonder if it would be cleaner to just have HTML always take care of setting the reserved client's top-level origin when it receives a response, so that Fetch and any other consumers don't ever have to think about the null case...

[annevk]

#5491 (comment) lays out some of the rationale around the current design. We could make top-level origin always return an origin. That might require some callers to check what kind of environment they are dealing with. I'm not sure we have enough callers to know what is better?

[annevk]

This needs some rewording as both reserved environment and client are members of something. And "i.e." isn't accurate either as this isn't a complete enumeration. Remember that environment is a subset of all environment settings objects.

[domfarolino]

I think I fixed up the comment about referencing the members. But I want to understand the i.e., comment better. I understand that environment is a subset of all environment settings objects, but still I believe the only two places where an environment is considered potential is when it is a reserved environment or reserved client, as in my i.e., enumeration. That is, the i.e., is referencing "potential", not the overall environment dfn.

(Also please ignore if the wrapping is off... I did this on the new github.dev UI to experiment with it; if it's malformed I'll fix it later on a real computer)

[domfarolino]

Thanks a lot for the context.

We could make top-level origin always return an origin. That might require some callers to check what kind of environment they are dealing with.

Can you clarify this? I think the only caller that expects a null top-level origin is fetch's determine the network partition key algorithm. If we make top-level origin always exist, I think we can remove that null check and then nobody has to check what kind of environment they're dealing with, right?

[annevk]

I'm wondering if there might be another consumer of this concept for which it returning null is useful (and they'd have to branch of the type of environment instead).

I think I also recall the reason now for why I went with null. It's because the environment doesn't have an origin (yet) and pretending it has one seemed somewhat dangerous.