Improve "populate request from client" for null client cases

[domenic]

In particular, set request's window to "no-window". Also assert that origin is always set for such null-client cases.

Omitting the template as this is more of an obvious bug fix.

/cc @ADKaster @trflynn89 @shannonbooth as this is a supplement to whatwg/html#11250 .

[domenic]

I'm not 100% sure this is correct.

As far as I can tell, request's window is used for showing dialogs, e.g. for WWW-Authenticate or client certs. Browser UI navigations probably still show those dialogs.

Maybe the issue is that request's window should really be something like request's traversable navigable? Because if we're just talking about where UI is shown, then it's not in a specific Window object. It's in a browser tab.

Unfortunately there are a lot of specs that seem to reference request's window... https://dontcallmedom.github.io/webdex/w.html#window%40%40request%40dfn I haven't audited them all.

[annevk]

This seems wrong for the null client case. Since I think a null client case is always a navigation (or perhaps something especially esoteric in the network stack) and thus would have a window to show dialogs in.

[domenic]

Upon reflection, I think most spec authors will use the null client case for things from the network stack. They won't necessarily be super-esoteric... just "browser features" like FedCM or similar.

So we might still want to do this automatically for them. Even if the browser UI navigation case goes a different path.

I'll leave this PR open in case we do want to go this route, and open a separate PR for the browser UI navigation path.

[annevk]

An end-user-facing dialog needs to be attributable to a specific authority, so I do think we want something like a Window or Document object here.

(Having said that, it's not clear to me that others are using request's window correctly. At least a couple of those cases I skimmed through should probably use the client instead.)

[domenic]

So to continue the discussion from #1820 (comment), after #1821 we'll have the browser UI case handled.

There remains an issue where Fetch currently states that if you have a null client, you only need to set up origin, policy container, service-workers mode, and referrer. This is incorrect: you also need to set up window. Right now the spec crashes as it tries to access the request's client's global object, when request's client is null.

There are two possible resolutions for this:

• Just add window to that list of things that are required to be set by callers.
• Automatically set window to "no-window" whenever it is left as the default "client" and client is null.

The latter is only appropriate if we think all non-navigation null-client cases really should suppress client certs/WWW-Authenticate/etc. I think that's probably correct, but maybe I'm wrong.

[annevk]

That is probably correct, yeah. Unfortunately #465 was never finished and the state in various browsers is a bit unclear to me at this point.

[domenic]

I think that's somewhat separable. Subresource requests will generally have clients. Null client cases are rarer, and will generally come from "background-ish" features like FedCM, Private Aggregation, Background Fetch.

Probably all of those can suppress the user prompts and just fail.

[annevk]

Marking as "do not merge yet" as per #1821 we should probably mostly get rid of request's window concept.