Chrome Version: (copy from chrome://version) 70.0.3537.0 (Official Build) canary (64-bit)
OS: (e.g. Win10, MacOS 10.12, etc...)  macOS 10.13.6

What steps will reproduce the problem?

<script>
const x = new XMLHttpRequest();
x.open('GET', 'data:text/plain,abc');
x.send();
x.onabort = () => { console.log("abort"); };
window.stop();
console.log("done");
</script>

What is the expected result?

"abort" is printed after "done". This is the case in Firefox.

What happens instead?

"abort" is printed before "done".

Unlike XMLHttpRequest's abort() method [1], window.stop() per spec does not have the synchronous abort event firing behavior. Instead, it just aborts the fetch, which bubbles down to "Queue a fetch task on |request| to process response for |response|" [2]. The "queue a fetch task" implies that the "process response" algorithm is to be run asynchronously. Then, the "process response" algorithm in XHR will fire the abort event [3][4]. 

Even more significant is that fact that firing the abort event synchronously allows an entire attack surface to be exposed. Issues like  bug 879366  is an exemplification of a crash that uses the fact that abort event is fired synchronously to detach the frame while some unsuspecting code that depends on the frame is running, thus wreaking havoc. In https://crrev.com/c/1198022, japhet@ mentioned "XHR onabort strikes again!" suggesting that this is a real systematic issue, and  bug 879366  is not alone.

While we should always have fixes for that class of bugs specifically, it might be worthwhile to align with Firefox and the spec and just fire the abort event asynchronously from places other than XMLHttpRequest's abort() method.

[1]: https://xhr.spec.whatwg.org/#dom-xmlhttprequest-abort
[2]: https://fetch.spec.whatwg.org/#ref-for-process-response%E2%91%A0
[3]: https://xhr.spec.whatwg.org/#ref-for-process-response
[4]: https://xhr.spec.whatwg.org/#handle-errors

Please use labels and text to provide additional information.

If this is a regression (i.e., worked before), please consider using the
bisect tool (https://www.chromium.org/developers/bisect-builds-py) to help
us identify the root cause and more rapidly triage the issue.

For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.