fix(http): emit error on XMLHttpRequest abort event

[ItNoN]

Fixes #22324

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• angular.io application / infrastructure changes
• Other... Please describe:

What is the current behavior?

Issue Number: #22324

Before this change, when Google Chrome cancels a XMLHttpRequest, an Observable of the response never finishes. This happens, for example, when you put your computer to sleep or just press Ctrl+S to save the browser page.

What is the new behavior?

After this commit, if request is canceled or aborted an appropriate Observable will be completed with an error.

Does this PR introduce a breaking change?

• Yes
• No

Other information

I was thinking about a new HttpEventType that tracks the abort event, but it seems to me that if forces beyond your control have decided your request is no longer going to continue, it looks more like an error.

I couldn't find a way to reproduce this bug with JSONP. It appears JSONP request is not aborted.

[AndrewKushnir]

@ItNoN thanks for the fix, the change looks good to me 👍

This change also looks related to #39807 and this PR will most likely require a rebase once #39807 lands (as they both update the same code).

I'm also adding @alxhub as a reviewer to this PR, since he participated in discussion in the original thread (#22324) and may have more context.

Thank you.

[ItNoN]

@AndrewKushnir, thank you for your quick response!
Yes, these PRs are very similar by structure. I'll make a rebase after #39807 is merged.

Thanks!

[alxhub]

I had some concerns originally, but I've convinced myself that this PR is good to go!

1. There is a question of whether abort events should be considered errors, or treated as a separate HttpEventType. I was leaning towards the latter, but after looking at the triggers for abort (beyond calling XmlHttpRequest.abort()), I think there's no value in differentiating them for users. Indeed - grouping all possible errors together is very useful.

2. This has nothing to do with the abort() we do when a request Observable is unsubscribed, because a. there is no possibility to emit values or errors after an unsubscription in general, and b. all event listeners are removed prior to that abort() anyway.

Therefore, I think this fix is good to go.

[AndrewKushnir]

@ItNoN, FYI PR #39807 has landed a few mins ago and that caused some merge conflicts for this PR (as expected). Could you please rebase this PR and resolve merge conflicts? Thank you.

[ItNoN]

@AndrewKushnir, done.

[AndrewKushnir]

FYI, presubmits are successful for the changes in this PR, adding "merge" label.

@ItNoN thanks for contributing to Angular!

[alxhub]

@ItNoN This PR unfortunately conflicts with the 11.2.x branch, so I can't merge it there. Can you open a separate PR against that branch directly? I'll go ahead and merge this to master.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}