Are 204/205 responses, downloads, or external software handoffs "successful" navigations or failures?

[domenic]

That is, what should navigation.navigate() return if you navigate to:

• A 204 or 205 response? In this case the browser will stay on the current page.
• A response with Content-Disposition: attachment? In this case the browser will start a download.
• A response with a content-type the browser doesn't know how to handle directly? In this case the browser will either start a download or launch an external app.

I feel like we have a few options:

1. Count all of these as an aborted navigation error, i.e. the returned promise rejects with an "AbortError" DOMException, navigateerror fires, etc. The mental model here is that navigation.navigate(url) is a request to go to url, and if we don't end up on url, we failed.

2. Count the 204/205 case as an aborted navigation error, but count the others as successful navigations which fulfill the promise and fire navigatesuccess once the download starts or the response is handed off. The mental model here is in the 204/205 case literally nothing got accomplished, so that's a failure, but in the other cases you succeeded at something, even if the URL didn't update.

3. Count all of these cases as a success. The mental model here is that we got to the end of the navigation process without errors (204/205 are technically success status codes!) so we should signal as such.

Related:

• Add the ability to navigate to a download or form submission #82 suggests adding an explicit navigation.navigate(url, { download: true }). We'd certainly want that to treat getting a download response as a success. And probably a 204/205 as a failure?

• Add the ability to navigate to a download or form submission #82 also allows a different model, where if you don't pass { download: true }, and the server sends Content-Disposition: attachment, we either ignore the server (novel capability; might be dangerous) or we abort the navigation without doing any download (and return failure).

• These cases are especially strange because so far we only resolve the returned promise/fire the events for same-document navigations, on the reasoning that for a cross-document navigation, the page is going away anyway. But in these cases the page is not going away, so we should really give either a success or failure instead of leaving things hanging. If we do what is suggested in Should appHistory.navigate()'s returned promise settle for cross-document navigations? #95 then this all becomes more uniform and we're always resolving the promise.

[tbondwilkinson]

I lean towards this being a success, as weird as it is.

I feel like a 204/205 should be the same user experience as navigating to a page and then navigating back.

I think without more intentionality with the navigate API (like download: true, where if the browser doesn't download something, it's a failure), it's hard to classify these as "wrong".

[dvoytenko]

I'd tend to think of this case as an aborted navigation because the stack hasn't changed, no transition took place, etc. In other words, from the navigational point of view these cases do not make sense. Although I could see how a browser that doesn't support downloads would work as: (1) navigate to the resource, (2) save the resource, (3) come back. In which case it's closer to what @tbondwilkinson is saying.

[domenic]

I feel like we have a few options:

I missed another option, which I believe is the current spec/Chrome behavior:

4. Treat all of these cases as cross-document navigations, and never resolve the returned promises or fire any events.

The downside of this is that most of the time you get a never-returned promise, it's because the page is being unloaded, so any promises/events are kind of useless and inaccurate.

So I think I still lean toward one of (1)-(3).

[annevk]

What I worry about with 1-3 is that they introduce a new timing channel. I think that means only 4 is reasonable, although I agree that it's far from ideal.

I could see splitting this based on the origin (accounting correctly for redirects will add complexity here) though. If we do that I think success makes the most sense when it's the same origin.

[domenic]

Great catch. I think you are right about a new timing channel... we simply give no information about when the destination server returned a 204/etc. today, as far as I can tell. (E.g., we don't fire unload/navigation timing in such cases, and we fire beforeunload way earlier, before doing the fetch to the destination server.)

Given that, splitting based on origin seems like it probably causes more confusion. The best story I think we could tell developers would be:

• If you're navigating cross-origin, a 204/etc. will always result in forever-pending promises.
• But if you're navigating same-origin, you'll get a settled promise.
  • ...unless your same-origin page redirects cross-origin, so, this isn't really a property you can tell by just looking at the call site; you also need to be sure you know what your server is doing.

Given that the main attraction of (1)-(3) would be to make developers never have to deal with forever-pending promises in documents that are sticking around, and we can't guarantee that benefit in cross-origin cases, I'm inclined to go with (4) uniformly.