I'm submitting a ... (check one with "x")

[ X ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

canActivate, canActivateChild will result in NavigationCancel event if 'false'/reject() happens in the Guard. Additionally the URL is reset to the base path before the navigation attempt (as though to leave the user on the page they navigated from).

This current behavior means that if you just go directly to a location in your browser (e.g. localhost:4200/some-guarded-route) and it returns false the URL will read "localhost:4200/" with a blank page as navigation is canceled.

Expected behavior

The right behavior to me seems that the router should try to see if there are further matches in the routing table (i.e. the guard 'false' case would cover the use case scenario of #14515). By continuing down the route table the behavior would be to land on '**' route in the worst case while also enabling conditional routing.

Minimally NavigationCancel event should determine if the resetUrlToCurrentUrlTree is an already displayed route (either rendering it if necessary or doing nothing if it's already rendered).

I will see if I can issue a PR to fix this for review. Will need to determine what the side effects would be for cases where people would expect just to stay on the currently rendered page (considering it was already rendered). However, to me I think the correct behavior for a dead link should be to go down the route table and hit '**' for a 404 or something vs doing nothing when the user clicks on it and rendering nothing if the user hits the route directly before any route has been rendered.

Minimal reproduction of the problem with instructions

Plunker won't work for this because you would need to be able to hit the route as though it was bookmarked to reproduce.

Effectively just create project using CLI, create a route guard, return false in the methods. Then attempt to hit the route directly without loading a root non-guarded route first.

What is the motivation / use case for changing the behavior?

Motivation is that you won't have the user on a blank screen if they happen to hit a guarded route without meeting the conditions.

Second part is that by resolving these scenarios by continuing down the route table you would enable conditional routing for scenarios such as:

Creating routes like:
localhost:4200/:organization
localhost:4200/:user

If the route guard found a valid organization it could allow the request to move forward vs user. This is all gravy. A start is to not give the user a blank page when resetting the route via resetUrlToCurrentUrlTree when the current Url wasn't rendered in the first place.

Please tell us about your environment:

Mac OS Sierra (10.12.4), WebStorm, NPM, ng serve

• Angular version: Angular 4.0.2

• Browser: Chrome 57

• Language: TypeScript 2.2.2

• Node (for AoT issues): node --version =
  Node 7.9