"abort" Event Isn't Fired When Aborting Document Load

[anthumchris]

Is firing an "abort" event still a valid HTML specification?

According to 7.8.12 Aborting a document load, "the user agent should...fire an event named abort at that Document's Window object". I've been testing with this abort event detection page and cannot capture the "abort" event anywhere from any browser.

Detecting the "abort" event in Service Workers would also be extremely useful, as we could effectively manage our Streams, FetchEvents, etc, and react accordingly. For example, this Service Worker Progress Indicator has no way to detect when the user signaled an abort/cancel on the page load. Firefox effectively cancels the download (without firing an "abort" event that SW can intercept, but Chrome does not)

[domenic]

Edge appears to fire it... although at the HTMLImageElement O_o

[wanderview]

I think the FetchEvent.request.signal should reflect if the intercepted request is aborted. I don't think we have a WPT test for this yet. We had some bugs in FF around it before, but it may work now or be easier to make work.

[anthumchris]

Thanks. Filed a Chromium bug:

https://bugs.chromium.org/p/chromium/issues/detail?id=818788

[domenic]

Should we still keep the event in the spec, given that only one browser seems to do it, and that browser does it wrong?

[anthumchris]

I think the abort event is important and needed because it reflects direct action and intent initiated by users. Users canceling/aborting/stopping page load is also a valid stage in an application's lifecycle. Making this event visible allows for more robust application development and gives options to developers when needed.

The browsers already correctly execute the stop/cancel functionality internally. Browsers would only need to report when that functionality occurs by firing abort.

[annevk]

We should probably remove this given that no browser implements it.

cc @jakearchibald