Repository navigation
Deactivation Guard breaks the routing history #13586
Description
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
Currently, I have a deactivation guard on a route which will return false or true depending on a condition. To get to this guarded route, the user must pass though 3 navigation step. Now, once on the guarded route, when using location.back(), the guard is called. If it returns true, the previous route is loaded. If the guard returns false, the navigation is cancelled. But if we redo a Location.back() after a failed navigation, the previous route that will be loaded will be 2 steps in the history instead of 1 (user perception).
Workflow
Main -- navigate to --> Route 1
Route 1 -- navigate to --> Route 2
Route 2 -- navigate to --> Route 3
Route 3 -- location.back() --> guard returns true --> Route 2
Route 2 -- navigate to --> Route 3
Route 3 -- location.back() --> guard returns false --> Route 3
Route 3 -- location.back() --> guard returns true --> Route 1 (should be Route 2)
Expected behavior
An expected behavior for a user would be that navigating back brings back to the previous routed page.
Workflow
Main -- navigate to --> Route 1
Route 1 -- navigate to --> Route 2
Route 2 -- navigate to --> Route 3
Route 3 -- location.back() --> guard returns true --> Route 2
Route 2 -- navigate to --> Route 3
Route 3 -- location.back() --> guard returns false --> Route 3
Route 3 -- location.back() --> guard returns true --> Route 2 (expected)
Minimal reproduction of the problem with instructions
Plnkr
- Click button Nav to route1
- Click button Nav to route2
- Click button Nav to route3
- Click button Block Nav Back
- Click button Nav back
- BOGUE: The location.back() routed on Route1 instead of Route2
Personnal investigation
After some investigation, I saw that in routerState$.then (router.ts line 752) this logic used when navigationIsSuccessful == false is pretty simply but it is the actual cause of this bug. Basically, when a deactivation guard is hit, the location of the browser is already changed to the previous route. Which means that when the guard returns false, the routerState$ runs his logic and calls resetUrlToCurrentUrlTree(). At this point we can see that we replace the state of the current location. But by doing this, we loose that route in the history which means that in my plunker, if we click the block nav back 3 times and then click the nav back we will actually kill the application.
What is the motivation / use case for changing the behavior?
This is for me a pretty big bug since a guard that returns false breaks alters the current routing history. In the case of our application this breaks the workflow and brings wrong business scopes to a user.
Please tell us about your environment:
Windows 10, NPM, Nodejs, Visual Studio 2015 (using nodejs for typescript compilation)
-
Angular version: 2.3.3
-
Browser: [ all ]
-
Language: [TypeScript 2.0.10 | ES5]
Activity
saverett commentedon Jan 13, 2017
A
Router.back()method wouldn't cover using the browser back and forward buttons though, correct? That seems to be the predominant use case.DzmitryShylovich commentedon Jan 13, 2017
yeah. So just returning history to the previous state is the only way I can think of here.
michelherv commentedon Feb 22, 2017
Hi,
I have the same problem in case of Activation Guard. Have I to create a new issue ?
DzmitryShylovich commentedon Feb 22, 2017
@michelherv yeah, reproduce on plunkr and file a new issue pls
michelherv commentedon Feb 22, 2017
@DzmitryShylovich done! You can found the description here #14645
szh commentedon Mar 30, 2017
This is still broken in Angular 4.0. Any plans to fix it?
DzmitryShylovich commentedon Mar 30, 2017
@szh please don't spam everywhere. Pr is here #13922
CRodriguez25 commentedon May 16, 2017
Is there a work around for this by any chance?
arutnik commentedon May 24, 2017
I couldn't find any workaround inside my candeactivate class. Still waiting for the PR
skaiser commentedon May 26, 2017
It seems it should work like resolve does, no? That is, it doesn't navigate until canDeactivate cancels or confirms whether the component can be deactivated (or routed away from). Otherwise, I don't really understand what it's purpose is.
CRodriguez25 commentedon May 26, 2017
Skaiser, its purpose is what you described, but there is a bug currently. A PR has been made to solve the issue, but until then the CanDeactivate guard breaks your history.
159 remaining items
refactor(router): compute correct history restoration when navigation…
atscott commentedon Jul 1, 2021
Hi, quick update here:
atscott commentedon Jul 16, 2021
The known issue mentioned above was fixed in the
12.1.2release this week. There are currently no known issues and it would be great if those interested in the fix could give it a quick test in their applications using the instructions above.mduft commentedon Jul 19, 2021
At first sight the fix seems to work perfectly, I couldn't reproduce a problematic case in our scenario anymore.
andrew-landsverk-win commentedon Aug 13, 2021
I am on
12.2.1and I have addedto the constructor in my
app.component.ts.Is there anything further I need to look at or do at this time?
liamdebeasi commentedon Aug 17, 2021
I can confirm that adding the code in #13586 (comment) resolves the issue for my use case (see: #43181)
jcn-ithaca commentedon Aug 18, 2021
The 'canceledNavigationResolution' fix worked in our application. (Note for thoroughness: I believe you have to also inject the router in the constructor);
Preview version of navigation fix activated.
angular-automatic-lock-bot commentedon Oct 3, 2021
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.