Don't onload / abort for 204 / 205 / "as download" responses

[annevk]

@Manishearth mentioned this in #511, but I didn't address that part of the issue, assuming it would be handled by simply aborting the navigation steps. It seems however that we are doing certain checks too late and/or aborting is happening too early. Seems like we should at least wait for the HTTP headers of a response to come back before deciding to actually continue with navigation or terminating it.

[Manishearth]

This should also happen for content-disposition: attachment files (not sure if they get a separate status, I think they just use 200 OK)

[annevk]

I basically need to write tests here I think. E.g., do we unload a document before we hear from the server? The current specification says yes, but does that match reality?

[annevk]

Actually, I'm not sure this is correct. This would suggest that synchronously doing prepare to unload and abort is wrong, whereas that's what browsers are doing. Firefox seems very inconsistent though when it comes to onbeforeunload and such. Perhaps it only does it for top-level browsing contexts?

[ericf01]

I'm having the same problem when posting a form that responds with a file download. The post cancels any in-progress AJAX requests issued by the current page. According to the current spec, the form post initiates navigation, which cancels the in-progress AJAX requests BEFORE receiving the status 200 response containing the content-disposition: attachment header. That header cancels the navigation, but can't reinstate the canceled AJAX requests. Based on extensive testing, both Google Chrome and MS Edge appear to have tweaked their algorithms to delay cancelation of the in-progress AJAX requests until the response headers can be examined. However, Mozilla Firefox obeys the published spec, thus experiencing the AJAX cancelation problem. Worse yet, if part of an AJAX JSON response has already been received when the form is posted, the post will truncate the response, resulting in a JSON parse error being thrown. I believe the official spec should be revised to work the way that Chrome and Edge have implemented, thus resolving this problem.

[annevk]

I was wrong above. We unload after (from a task in history), we prompt to unload (beforeunload) before (synchronously from navigate). So it might be that everything is in order here, but should probably test again to be sure.

[annevk]

@ericf01 I think your issue is slightly different, though also important to sort through and test. It's more related to #1334 (in particular the last comment). Tests for that would also be good.

[ericf01]

I originally posted this issue in #1382 at the suggestion of @bzbarsky, with whom I discussed a resolution of this issue in Mozilla Firefox. I am reposting it here at the suggestion of @annevk, who thought it was more related to #1334: I'm having a problem when posting a form that responds with a file download. The post event cancels any in-progress AJAX requests issued by the current page. According to the current spec, the form post initiates navigation, which cancels the in-progress AJAX requests BEFORE receiving the status 200 response containing the content-disposition: attachment header. That header cancels the navigation, but can't reinstate the canceled AJAX requests even though the page that issued the post remains the current page. Based on extensive testing, both Google Chrome and MS Edge appear to have tweaked their algorithms to delay cancelation of the in-progress AJAX requests until the response headers can be examined. However, Mozilla Firefox obeys the published spec, thus experiencing the AJAX cancelation problem. Worse yet, if part of an AJAX JSON response has already been received by Mozilla Firefox when the form is posted, the post will truncate the JSON response, resulting in a JSON parse error being thrown. I believe the official spec should be revised to work the way that Chrome and Edge have actually implemented it, thus resolving this problem and yielding the expected results on the current page.

[annevk]

That's the same comment as far as I can tell. In any event, to make progress we need tests. A pointer to the where you discussed this would also be good (if it's a public bug report or mailing list or some such).

[ericf01]

Yes, it's the same comment. I thought you wanted me to move it from #1382 to #1334.

A full discussion of the issue, involving a work-around for Mozilla Firefox from @bzbarsky including his suggestion that it be posted in #1382, can be reviewed at https://bugzilla.mozilla.org/show_bug.cgi?id=1315741.