Router: skipLocationChange is routing to root.

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

The skipLocationChange in the router used to change the component and keep the url as it was.
Expected behavior

The skipLocationChange in the router would change the component without changing the route.
Minimal reproduction of the problem with instructions

http://plnkr.co/edit/F2YVpAV1EtNUolNgFClR?p=preview
What is the motivation / use case for changing the behavior?

Redirections to 404's etc should not change the url
Please tell us about your environment:

Angular version: 4.0.X

Was working correctly in 2.0.X

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

all

Language: [all | TypeScript X.X | ES6/7 | ES5]
Typescript
Node (for AoT issues): node --version =

I guess this needs a Plunker to reproduce to become a valid bug report.

I'm having this problem too with Angular 4.1.1.

The problem with trying to make a Plunker for this issue is that in Plunker the URL will not change like it would if you were running the app normally (w/out Plunker). For example, this Plunker from the Routing & Navigation tutorial: https://angular.io/resources/live-examples/router/ts/eplnkr.html

Trying to come up with a simple reproduction of the problem... In the meantime, this seems to be what's happening in my scenario:

App is launched by going to a url like "/abc", where "abc" is a route parameter.

There is a guard for the this route, and it may decide to navigate and skip the location change.

Before navigating, the url property of Router is "/", however, the Location service returns the url as "/abc" (via Location.path()).

So in this scenario, the router thinks the current URL is "/" when it's really not. So I'd say that the skip location change logic is working, but somehow the router seems to be misguided about the current url.

My issue is also from a guard so it might be guard related.Trying to do a plunk up at the moment.

@sunild

Actually getting a different issue in my plunker, run out of time to work on this but this is a start: http://plnkr.co/edit/F2YVpAV1EtNUolNgFClR?p=preview @sunild You can open it up in a separate window if you have time to complete my plunker.

ok my mistake, the above actually works so it must be specific to the redirect happening in the guard. I will try and reproduce

ok http://plnkr.co/edit/F2YVpAV1EtNUolNgFClR?p=preview demonstrates the issue, in component two I have a navigate in the guard, the url should be that of component 2 (it was in angular2).

@zoechi

@zoechi any update on this getting fixed? I have attached a preview to show the issue.

actually I have found a workaround, there must be an easier way to get the current url though:

route.pathFromRoot.map((routes: any) => {
   return routes.url.map((urlSegment: UrlSegment) => {
     return urlSegment.toString();
   }).join('/');
}).join('/')

Any news on this issue? I do have exactly the same behavior in 4.3.5.

+1
Same issue here. Version 4.4.6

Running into the same thing here too.

This should have been fixed with #20803. Can you please verify?

This appears to have been resolved at some point. I copied the example to stackblitz and ran with v9: https://stackblitz.com/edit/angular-ivy-gvrcne?file=src/app/app.module.ts
Clicking the route2 link results in the component for route 3 being shown (and the url remains the same). I believe this is the expected behavior.

If after upgrade the problem still exists in your application please open a new issue and follow the instructions in the issue template.

It hasn't actually, in your example when manually routing to /route2 you see it redirects to root, not route3 nor route2. Problem still exists in angular 9.1.11

It hasn't actually, in your example when manually routing to /route2 you see it redirects to root, not route3 nor route2. Problem still exists in angular 9.1.11

I see. So the issue being reported is that direct navigations reset the url to the root if a guard returns false? This is a separate issue from skipLocationChange is really working as intended. By returning false from a guard, the navigation to the route is cancelled and the URL is reset. If there is no previous URL to reset to, the router falls back to the root. The navigation with skipLocationChange is a separate navigation and shouldn't use the URL from a cancelled navigation.

Guards prevent navigation to a route. The expectation that the router not reset the URL if a guard returns false is not how it's intended to work.
~~If a second navigation is called during an in-flight navigation, the first is cancelled and the URL is also reset. Behavior would otherwise be very unpredictable.~~ Edit: After further review, this is not the case. The URL is actually only reset when a new navigation cancels an in-flight one to support AngularJS by adding the navigationId to the state. We probably shouldn't do this.

I'm re-opening this as a feature request to provide some way of redirecting from a guard while keeping the browser URL the same. Returning a UrlTree from the guard is close but doesn't provide the ability to use skipLocationChange to keep the URL of the attempted navigation.

Arrive here having the same issue, manual navigate from a guard change path to root, angular version 9.

I'm re-opening this as a feature request to provide some way of redirecting from a guard while keeping the browser URL the same. Returning a UrlTree from the guard is close but doesn't provide the ability to use skipLocationChange to keep the URL of the attempted navigation.

Is there a solution to this issue?

I am using Angular 11 and need exactly this feature. I want to implement a 403 (Forbidden) component but the URL must stay the same when the guard returns false (or UrlTree). So the user can just reload by F5 when provided correct permissions.

I'm re-opening this as a feature request to provide some way of redirecting from a guard while keeping the browser URL the same. Returning a UrlTree from the guard is close but doesn't provide the ability to use skipLocationChange to keep the URL of the attempted navigation.

Is there a solution to this issue?

I am using Angular 11 and need exactly this feature. I want to implement a 403 (Forbidden) component but the URL must stay the same when the guard returns false (or UrlTree). So the user can just reload by F5 when provided correct permissions.

Unfortunately not a good one at the moment, no. #27148 has some more discussion about workarounds other devs have created.
Closing as duplicate of #27148

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.}

Navigation Menu

Repository navigation

Router: skipLocationChange is routing to root. #16981

26 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Router: skipLocationChange is routing to root. #16981

Description

Activity

zoechi commented on May 24, 2017

sunild commented on May 31, 2017

sunild commented on May 31, 2017

damiandennis commented on May 31, 2017

damiandennis commented on May 31, 2017

damiandennis commented on Jun 1, 2017

damiandennis commented on Jun 1, 2017

damiandennis commented on Jul 25, 2017

damiandennis commented on Jul 26, 2017

vapits commented on Aug 23, 2017

SeverinAlexB commented on Nov 13, 2017

NickGeek commented on Nov 29, 2017

jasonaden commented on Dec 12, 2017

26 remaining items

spaaacetoast commented on Jun 14, 2020

atscott commented on Jun 15, 2020

xavadu commented on Oct 8, 2020

adestis-ds commented on Apr 29, 2021

atscott commented on Apr 29, 2021

angular-automatic-lock-bot commented on May 30, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions