- From: Domenic Denicola <notifications@github.com>
- Date: Wed, 30 Apr 2025 23:40:29 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/pull/1821/c2844203393@github.com>
domenic left a comment (whatwg/fetch#1821) > 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|???| |Cross-origin link click |Blank, URL bar updates|Blank, URL bar updates|???| |Same-origin URL bar nav |Blank, URL bar updates|Old page backdrop, URL bar updates|???| |Cross-origin URL bar nav|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?) -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/pull/1821#issuecomment-2844203393 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/fetch/pull/1821/c2844203393@github.com>
Received on Thursday, 1 May 2025 06:40:33 UTC