whatwg
Should downloads be "navigate" or "no-cors"
Currently in the standard some downloads are the result of navigation and others are the result of the download attribute, which ostensibly fetches directly, but can also navigate, e.g., if you use <a download=x href=https://www.example.com/>test</a> outside of example.com.
I suspect that due to redirects and such it really should just be an input to the navigate algorithm and therefore the mode ought to be "navigate".
This disconnect has a broader impact now due to the existence of the Sec-Fetch-Mode header, see https://bugzilla.mozilla.org/show_bug.cgi?id=1637747.
(I'm pretty sure this was discussed before, but I cannot find the issue.)
cc @mikewest @ckerschb
Chromium has also implemented this with the request mode "navigate."
https://bugs.chromium.org/p/chromium/issues/detail?id=1082429
This has some implications for CORB, as noted in fetch:
If request’s initiator is "download", then return allowed.
If we recast downloading as navigation this step can be removed.
The pull request which introduced that note may contain the discussion @annevk's thinking of.
I'm having some trouble understanding the distinction between "mode" and "destination" in this case. That may partly be due to the term "navigation request"--a request whose destination is "document." It seems strange that a request can have a mode of "navigate" but not be considered a "navigation request."
I suspect we'd change destination to "document" as well here, though perhaps adding "download" would make sense (and redefining navigation request appropriately).
Chromium implements both kinds of downloads as navigate. It seems reasonable to me for us to bake that into the spec, especially given the behavior @annevk notes above.
If you'd like to add download as a special kind of navigation type that comes from <a download>, I could live with it, but it's not clear to me what the value would be of doing so?
There's mode and there's destination. It sounds like we agree that mode should be "navigate". Should destination be "document" as it is for other navigations? That seems fine to me, but I thought I'd offer a different value. (Thinking about it some more a different value might be tricky though given the cross-origin behavior and redirects and such.)
Looks like neither the spec nor Chrome consider target in the download flow (here's Chrome's code), which might simplify things.
That's not entirely true, see #7718. <a href="https://example.com/" download target=_blank>Click me</a> will open a new tab. It might be interesting to test what happens if it were to first navigate same-origin and then redirect. (As opposed to window.open() nothing has to be returned synchronously here so there is a bit of leeway to optimize UX.)
Sorry, I meant the download-only path does not respect target. The fallback-to-normal-navigation-in-a-way-that-goes-against-the-spec path is just a normal navigation, which of course respects target and so on, as if we never had the download attribute at all: https://browsing-context.glitch.me/download.html.
But at least in Chrome, if the download-only path is hit (conditions are here) target plays no role.
CSP is apparently applied differently between download and not-download in Chromium, see https://bugzilla.mozilla.org/show_bug.cgi?id=1862553
Also while I was investigating this, I found that the initiator value "download" (set here) appears to be dead code in the specs.
I posit that downloads are inherently a "top-level navigation," and should be treated as such.
