Replace request's "window" with "traversable for user prompts" #1823
Conversation
After much discussion in #1820 and #1821, this seems to be more correct. Closes #1820. Closes #1821. Helps whatwg/html#11250 specify browser-initiated navigations better.
domenic
added
the
do not merge yet
| <a for="environment settings object">global object</a> is a | ||
| {{Window}} object). Unless stated otherwise it is | ||
| "<code>client</code>". | ||
| <dfn export for=request id=concept-request-window>traversable for user prompts</dfn>, that is |
There was a problem hiding this comment.
I'm trying to write out "end user" where I can myself. I'm not actually sure where we are consistency-wise, but is that something we can strife for? I'm happy to document it as the term to use.
There was a problem hiding this comment.
Hmm, why? It seems excessively verbose...
There was a problem hiding this comment.
Well, it's only four additional characters. Still shorter than implementer. "Person who operates the computer" might qualify for excessively verbose. 😛
To me it sounds a bit nicer and feels more respectful.
There was a problem hiding this comment.
I dunno, it seems a lot of churn across the ecosystem, and causes me to wonder "what's the difference between an end user and a user"? (Or is it "end-user"?)
I don't really understand the more respectful bit either.
There was a problem hiding this comment.
In case it helps, after all the PRs linked in the OP land, only one spec (Permissions Policy) will actually use "traversable for user prompts", so it'd be pretty easy to change later if we do decide on a larger ecosystem movement from user -> end user.
There was a problem hiding this comment.
I think https://datatracker.ietf.org/doc/html/rfc8890 captures best why I'd like to make this change, though arguably you could try to define "user" in the same way.
Anyway, happy to drop this for now.
| agent should avoid displaying content from the request's initiator in the | ||
| <a for=request>traversable for user prompts</a>, especially in the case of cross-origin requests. | ||
| Displaying a blank page behind such prompts is a good way to fulfill these requirements. Failing to | ||
| follow these guidelines can confuse users as to which origin is responsible for the prompt. |
There was a problem hiding this comment.
| follow these guidelines can confuse users as to which origin is responsible for the prompt. | |
| follow these guidelines can confuse end users as to which origin is responsible for the prompt. |
fetch.bs
Outdated
| <var>httpFetchParams</var> to <var>fetchParams</var> and <var>httpRequest</var> to | ||
| <var>request</var>. | ||
|
|
||
| <p class=note>If user prompts are possible, then we need to clone <var>request</var> because ??? |
There was a problem hiding this comment.
Because it's one of the scenarios where we might have to repeat request.
There was a problem hiding this comment.
I added that, although I'm not 100% sure I understand when that would happen. Who gets the request the first time, and who gets it the second time? Does this occur for all 3 possible prompt causes (WWW-Authenticate, PACs, and TLS client certs) or just some of them?
There was a problem hiding this comment.
It happens when you do a request and the server returns a challenge. Then you have to repeat the request addressing the challenge. This happens with HTTP authentication at least. I'm not sure about client certificates as they happen at the TLS level, so maybe not?
There was a problem hiding this comment.
Right, OK, I think I forgot some details. But to recap:
- Clients optimistically send the body to the server before getting the response headers back.
- Certain response headers mean you need to restart the entire request, with a new set of request headers.
Let me see if I can tweak the wording here to make it a bit more obvious, without necessarily restating too much...
Per whatwg/fetch#1823, this concept is going away. After that change, null-client scenarios will automatically do the right thing, and create no user prompts, which aligns with this spec's desired outcome.
Per whatwg/fetch#1823, this concept is going away. Instead, use the request's client, which is equivalent for this spec's purposes.
Per whatwg/fetch#1823, this concept is going away. After that change, null-client scenarios will automatically do the right thing, and create no user prompts, which aligns with this spec's desired outcome.
Per whatwg/fetch#1823, this concept is going away. Instead, use the request's client, which is equivalent for this spec's purposes.
Per whatwg/fetch#1823, this concept is going away. After that change, null-client scenarios will automatically do the right thing, and create no user prompts, which aligns with this spec's desired outcome.
Per whatwg/fetch#1823, this concept is going away. Instead, use the request's client, which is equivalent for this spec's purposes.
Per whatwg/fetch#1823, this concept is going away. Instead, use the request's client, which is equivalent for this spec's purposes.
domenic
removed
the
do not merge yet
Per whatwg/fetch#1823, this concept is going away. After that change, null-client scenarios will automatically do the right thing, and create no user prompts, which aligns with this spec's desired outcome.
Per whatwg/fetch#1823, this concept is going away. After that change, null-client scenarios will automatically do the right thing, and create no user prompts, which aligns with this spec's desired outcome.
Per whatwg/fetch#1823, this concept is going away. After that change, null-client scenarios will automatically do the right thing, and create no user prompts, which aligns with this spec's desired outcome.
Per whatwg/fetch#1823, this concept is going away. Instead, use the request's client, which is equivalent for this spec's purposes.
After much discussion in #1820 and #1821, this seems to be more correct. User prompts are not tied to specific
Windows, and certainly not to the client'sWindow. They are tied to a traversable navigable, i.e. "browser tab", and that browser tab should ideally be blanked out and updated to reflect that it's the destination that's causing the prompt, not the request client.Closes #1820. Closes #1821. Helps whatwg/html#11250 specify browser-initiated navigations better.
(See WHATWG Working Mode: Changes for more details.)
Places to update, from https://dontcallmedom.github.io/webdex/w.html#window%40%40request%40dfn:
Preview | Diff