Handle request's window when from browser UI

[domenic]

In whatwg/html#11250 we are working to specify browser UI-initiated navigations better. Without this change, it is unclear what to set their request's window to. They will have null clients, so "client" is not appropriate. They will show prompts, so "no-window" is not appropriate. And setting it to whatever's shown currently in the being-navigated window is not correct.

This introduces a new value, "from-browser-ui", which indicates that browser UI is initiating the request, and so any prompts should still be shown, but on a neutral backdrop, not associated with a specific Window object.

• At least two implementers are interested (and none opposed):
  • This matches Chrome's behavior
  • This mostly matches Firefox's behavior, although for Firefox, if you go to http://labs.w0s.jp/http/authorization/ and then enter http://labs.w0s.jp/http/authorization/basic/ in the address bar, it does not blank out the page. (Whereas if you go https://example.com/ and then enter http://labs.w0s.jp/http/authorization/basic/ in the address bar, it does blank out the page.) I think it's OK to say that Firefox is violating this minor part of a "should" requirement.
  • I haven't tested Safari yet.
• Tests are written and can be reviewed and commented upon at:
  • This seems basically impossible to test.
• Implementation bugs are filed:
  • Chromium: N/A
  • Gecko: Doesn't feel worth it for this minor divergence
  • WebKit: … TODO after testing, in the event they do something very strange
  • Deno (not for CORS changes): N/A
• MDN issue is filed: N/A, too detailed
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[annevk]

I was about to approve this, but now I'm doubting it again. Is "from-browser-ui" really correct here?

If I'm on a.com and click a link to b.com and b.com requires an end-user dialog, in that case we want the blank window as well, right? Perhaps the window cannot really be inferred from the client at all?

[annevk]

Should we note here that the address bar should probably contain some variation on the request's current URL?

[annevk]

Suggested change

	dialog available in <var>request</var>'s <a>appropriate user prompt context</a>.
	dialog available therein.

Might be a bit nicer.

[domenic]

If I'm on a.com and click a link to b.com and b.com requires an end-user dialog, in that case we want the blank window as well, right?

You're right.

Let me document my findings:

	Chrome	Firefox	Safari
Same-origin link-click	Blank URL bar updates	Old page backdrop no URL bar update	Old page backdrop URL bar updates
Cross-origin link click	Blank URL bar updates	Blank URL bar updates	Blank URL bar updates
Same-origin URL bar nav	Blank URL bar updates	Old page backdrop URL bar updates	Old page backdrop URL bar updates
Cross-origin URL bar nav	Blank URL bar updates	Blank URL bar updates	Blank URL bar updates

Here:

• Same-origin is http://labs.w0s.jp/http/authorization/ to https://labs.w0s.jp/http/authorization/basic/, via either link click or entering the second URL in the URL bar.
• Cross-origin is https://boom-bath.glitch.me/link-to-basic-auth.html to https://labs.w0s.jp/http/authorization/basic/, via either link click or entering the second URL in the URL bar.

and

• "blank" = the backdrop is blanked out
• "old page backdrop" = the referrer page is left in place as a backdrop, although usually tinted darker
• "no URL bar update" = the URL bar contains the referrer page URL during the prompt display
• "URL bar updates" = the URL bar updates to the new page URL during the prompt display

Honestly, Chrome's approach seems best here. It's really the response URL that is prompting you; the referrer (i.e., the request's window) is not really the party we should be attributing the prompt to.

We could still track the top-level traversable ("browser tab") if we thought that was useful, as a hint to implementations about where to display the prompt. That is, implementations should display the prompt in the place where the response is eventually going to show up, if the navigation succeeds.

But I think tying it to the referrer Window, as the current spec does, doesn't make sense.

Maybe if testing Safari reveals that it does something more like Firefox, we could consider speccing that sort of behavior... but I still don't like it. (I'm sick and working from home this week so I don't have access to my testing Mac. But maybe you could fill in the results?) Safari now tested, and behaves somewhat similar to Firefox

[domenic]

I guess part of the issue is that TLS client certs are caused by the request, but WWW-Authenticate or proxy-authentication entries are caused by the response. I'm only testing WWW-Authenticate above.

[valenting]

Firefox's behaviour was changed in 791594 - 401 password prompt spoofing thing
@Trikolon or @dveditz might have some thoughts about this.

[annevk]

Based on https://jpassing.com/2021/09/27/do-browsers-use-client-certificates-to-authenticate-the-user-the-device-or-both/ and some other search results it seems that client certificate dialogs can also be driven by the response.

I agree that would be a much better way forward here. We probably do want to track the navigable to make sure we know where to present the dialog. And that navigable then needs to figure out whether a blank interstitial is required.

[Trikolon]

For Firefox we only changed the behavior (blank page, url bar updated) for cross origin sites to avoid spoofing. Demo: https://eviltrap.site/trap/http-auth-prompt-spoof/. For same-origin that's not really a concern.

I'm in favor of aligning with Chrome and inserting a blank interstitial for both cross and same origin cases to make the behavior more consistent.