cancelling routes #2109

geddski opened this Issue Mar 6, 2013 · 14 comments


None yet
geddski commented Mar 6, 2013

There is currently no good/documented way of canceling a route change.

event.preventDefault() can be used with $locationChangeStart but that event doesn't fire from the back button (bug?)

$routeChangeStart does fire on back button, but its preventDefault() method doesn't actually prevent the route from changing (bug?)

Related issues: #592 #665 #1569


Locationchangestart event should do the trick if it doesn't then that's a bug. Can you repro this?

geddski commented Mar 7, 2013

I'm playing around with simulating a back button in the locationSpec, but it's having no effect on $location.url():

$location.url() // 'somePath'
$location.url() // 'somePath' still
$location.url() // 'somePath' still

Maybe that's part of the problem.


Any idea when this will make into one of the "unstable" builds? This is a show stopper when a controller needs to track dirty data and prevent navigation away from a view (or at least prompt the user). Thanks for the fix though quazzie.

@petebacondarwin petebacondarwin added a commit that closed this issue May 1, 2013
@quazzie @petebacondarwin quazzie + petebacondarwin fix($location): back-button should fire $locationChangeStart
Before $locationChangeStart event is not broadcast when pressing the back-button on the browser.

Closes #2109
@petebacondarwin petebacondarwin added a commit that referenced this issue May 1, 2013
@quazzie @petebacondarwin quazzie + petebacondarwin fix($location): back-button should fire $locationChangeStart
Before $locationChangeStart event is not broadcast when pressing the back-button on the browser.

Closes #2109

Calling $route.reload() in $routeChangeStart seems to prevent the route from changing.


The event $locationChangeStart has as it's second parameter the 'next' route but all it shows is the full path: "http://localhost:3000/#/users" Surely if you expect people to use this to cancel routes it should include only the /users (for example) part of the path as $routeChangeStart event does with it's 'originalPath' property.

Right now we're forced to parse the URL to use this.

These inconsistencies need to be cleaned up, they make it a nightmare to learn angular.


I tried $route.reload in $routeChangeStart but it seems to cause a loop and the page freezes (Angular 1.2.7).


@nickspacek I had the same problem. I resolved it by injecting $location and calling $location.url('original/path/1') instead of $route.reload() and it worked well. I think this is because by the time the $routeChangeStart event fires, the Angular internals have updated a property to the new route and $route.reload() continuously reloads the new route regardless if you're trying to prevent it from happening.

As @WhatFreshHellIsThis mentioned there are inconsistencies with the arguments for $locationChangeStart and $routeChangeStart. It'd be nice if they were in sync, I wonder if there's a reason to expose the naked URLs for the $locationChangeStart arguments instead of sugared JS objects.

In my case, on $routeChangeStart, I am sniffing the next argument for to determine if the user is allowed to access a manually entered URL hash.

The downside to my $location.url() solution is that it triggers a page transition while returning to the same page.

zulrang commented Jun 16, 2014

I'm having a similar issue where I want to authenticate the route change by examining the sugared next parameter and cancelling the route change in the case where the user isn't authorized.

This seems like a very basic feature that should have a clean solution.

Darmikon commented Jul 2, 2014

event.preventDefault() method in $routeChangeStart event callback still doesn't prevent route change and actually does nothing

$scope.$on('$routeChangeStart',function (event, next, current){
        console.log("I didn't prevent route change");
$scope.$on("$locationChangeStart", function(event, nextUrl, currentUrl) {
        console.log('I prevented route change');

as @zulrang said - I'm trying to do the exact same thing... big time bummer.


@OakBehringer can't you just add a resolve dep that runs the check in routes that require authentication? as an added bonus you can offer your user object to the controller.


We do this. I added a provider which the resolve property of the router utilizes. It tests a variety of auth conditions and either redirects the user to their destination or back to the login screen. We apply this provider to all routes and use API header authentication, combined with Rails sessions to allow a session to persist over multiple visits. At least... I think that's what we have, I'm definitely a UI guy.


Nothing helps me for v0.2.18.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment