This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the spec https://html.spec.whatwg.org/multipage/browsers.html#navigating-across-documents on step 12 invokes https://html.spec.whatwg.org/multipage/browsers.html#abort-a-document. In practice the majority of browser implementations (Chrome, Internet Explorer) do not invoke abort-a-document from navigating-across-documents in step 12. Only a minority of browser implementations (Firefox, Safari) implement navigating-across-documents according to the spec and will invoke abort-a-document in step 12. I think that not invoking abort-a-document from step 12 of navigating-across-documents is better. At the time of step 12 it is impossible to tell whether the navigation in progress will result in unloading the current document. If for instance the response from the server is not rendered in the browser (content-type not supported or because server sends a content-disposition: attachment header), then the current browsing context will continue to live on past the navigation. For this reason i think that aborting the document is premature here and will leave the current document in a corrupted state if the navigation does not result in a new document being loaded in the current browsing context. For browser based software components, it is hard if not impossible to tell request aborts that happen as part of step 12 from request aborts that happen for any other reason (i.e. tcp connection loss) and therefore it is hard to properly deal with step 12 invoking abort-a-document. Abort-a-document (which titles "Aborting a document load") is used for two cases: when the user hits the stop button (only possible before the document has fully loaded) and from navigating-across-documents, step 12 (no matter if the document is fully loaded or not). I think that the steps in abort-a-document are suitable for the stop button but are not suitable for invoking in an early phase of a navigation. I have built a test application that tests whether browsers abort requests in step 12 of navigating-across-documents. The test application is attached to this issue and can be accessed online at http://lab-browserillegalrequestabort-1.unblu.com/ I have also filed bugs reports with mozilla (https://bugzilla.mozilla.org/show_bug.cgi?id=1084399) and webkit (https://bugs.webkit.org/show_bug.cgi?id=137817) prior to filing a bug here.
Created attachment 1550 [details] Test application that tests whether a browser aborts requests in stem 12 of navigating-across-documents (also available here: http://lab-browserillegalrequestabort-1.unblu.com/)
Please make sure to check what browsers do with extant navigations, in both the document and its subdocuments.
@Boris Do you think it makes sense to add tests for nested browsing context? If so: here is my suggestion of tests to be added: 1. - Start a request (ajax or image) in a nested browsing context - Start navigation in the root browsing context - Check if the request (ajax or image) is aborted 2. - Run all existing tests inside a nested browsing context Is there anything else you think i should add?
Yes. You need to add this: - Start a navigation in a nested browsing context - Start navigation in the root browsing context that then fails to actually load a new page. - Check whether the navigation in the nested browsing context completed.
Created attachment 1554 [details] Test application that tests whether a browser aborts requests in stem 12 of navigating-across-documents (also available here: http://lab-browserillegalrequestabort-1.unblu.com/) added support for testing inside nested iframe
I have added tests for nested browsing contexts as described by boris. Check the "use nested iframe" checkbox and all tests will run as follows: A request (image, ajax or websocket) is created inside a iframe. While the request is still pending, a navigation is started in the top browsing context If the request is aborted due to the navigation in top, the test is regarded as failed.
Created attachment 1555 [details] Test application that tests whether a browser aborts requests in stem 12 of navigating-across-documents (also available here: http://lab-browserillegalrequestabort-1.unblu.com/) added an additional request type 'iframe' to the tested request types (ajax, image, iframe and web socket). The iframe test type is different from the nested test option added in the previous version. The nested option performs the tests inside an iframe, the iframe test type tests whether a navigation inside an iframe is also aborted as part of step 12 of a navigation in the parent browsing context.
Mirko, do you have a summary of what browsers are doing for the various scenarios? From a distance, my impression is that we should cancel all network activity when the document is being teared down, not necessarily early on when navigating. The fact that per https://bugzilla.mozilla.org/show_bug.cgi?id=896666 WebSocket and EventSource are somehow different while they are conceptually the same (both use Fetch) illustrates to me there's indeed a problem of sorts here.
> we should cancel all network activity when the document is being teared down Last I checked, the web relies on browsers NOT doing that (e.g. starting fetches from unload events and having them actually complete, though we have been trying to get people away from doing that).
I have moved the test app to git hub: https://github.com/mirkotschaeni/w3org-27347-illegal-request-aborts In short with recent versions: Chrome and IE would never abort fetches just because of a started navigation. Safari would abort "normal" fetches (ajax, loading iframes...) but not websockets Firefox would abort "normal" fetches (ajax, loading iframes) and also websocket but not in all cases. For a more detailed report i would need to invest more time... Whether or not network activity should be canceled when a document is teared down is not exactly the core issue described here but from a distant view i would say it would make sense. The core issue here is that some browsers do actually cancel network activity even it the document is NOT teared down! ...but just because a navigation has started which will then result in something that will not tear down the document (i.e. a download).
https://github.com/whatwg/html/issues/4489