🐞 Changing the URI in the browser directly will fire guards and resolvers of the route TWICE

Affected Package

The issue is caused by package @angular/router when using "useHash: true"

FYI / Heads Up: This issue is reproducible in Firefox based browsers ONLY - so it MAY be a browser bug (emitting the 'popstate' / 'hashchange' events). On the other hand - it may be working in Chromium based browsers because of sheer race-condition luck, I don't know.

This issue is reproducible with Waterfox G3.2.1 64-Bit (which is based on Firefox ESR), and the up-to-date (as of this writing) versions of regular Firefox and its Developer Edition.

Description

When changing the URL in the browser's location bar directly - by

• copy/pasting a link from an email into it
• dragging a link from the Angular app into it
• or just manually typing it

the guards and resolvers of this route will fire TWICE each.

This is especially bad when the resolver is trying to get a LOCK for a mutable resource!!
Weird things happen: While the component to update the resource is about to be created by the Angular router, the second resolve fails (because the resource is locked now) and redirects the user to some kind of resource overview page. So the lock is now being held by US (unknowingly).

🔬 Minimal Reproduction

https://stackblitz.com/edit/angular-11-hashchange-bug
Please remember the issue only manifests when dragging the link into the URI bar.
Clicking the links (and thus opening a new window) works as expected. 👍

Demonstration

Expectation:

1. the guard will fire (once!)
2. on error the router redirects (once!)
3. on success the routing process continues
4. the resolver will fire (once!)
5. on error the router redirects (once!)
6. on success the lock.component is created and everything is fine

Outcome:

As you can see, the guard and resolver fire twice for a single URI change. The outcome is based on the combination of whether the guard and the resolver are succeeding or not. There are multiple variants, the worst one being the one described above at 'This is especially bad...'.
But if the resource was locked (e.g. by a third-party) already - it can result in double error boxes, etc.

Here is a browser log of a case:

After the routing to '/redirect-to' just finished (NavigationEnd / Scroll) - just milliseconds later the router is detecting a request to route to '/lock-something' again (with navigationTrigger: "hashchange") and re-starts the navigation (NavigationStart) - including all guards and resolvers of course! 😶

🌍 Your Environment

     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/


Angular CLI: 11.2.10
Node: 14.13.1
OS: win32 x64

Angular: 11.2.11
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router
Ivy Workspace: Yes

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1102.10
@angular-devkit/build-angular   0.1102.10
@angular-devkit/core            11.2.10
@angular-devkit/schematics      11.2.10
@angular/cli                    11.2.10
@schematics/angular             11.2.10
@schematics/update              0.1102.10
rxjs                            6.6.7
typescript                      4.1.5

P.S.: This bug sounds a lot like it should've been squashed by this PR: #37674
But it still remains in Angular 11.2.11