Router functionality broken from 1.3.5 to 1.3.6 in some specific cases

[machacz]

HTML code (outside ng-app):

<p>
      <a href='#/one/10'>Trinity</a> | 
      <a href='#/two/200/20'>Morpheus</a> | 
      <a href='#/three/3000/300/30'>Neo</a> |
      <a href="index.html?test=abc">Test</a>
</p>

JavaScript:

routingiApp.config(['$routeProvider',
            function ($routeProvider) {
              $routeProvider.
                      when('/one/:oneId/', {
                        templateUrl: 'templates/one.html',
                        controller: 'oneController'
                      }).
                      when('/two/:oneId/:twoId/', {
                        templateUrl: 'templates/two.html',
                        controller: 'twoController'
                      }).
                      when('/three/:oneId/:twoId/:threeId/', {
                        templateUrl: 'templates/three.html',
                        controller: 'threeController'
                      }).
                      otherwise({
                        redirectTo: '/one/123/'
                      });
            }]);

The issue: Clicking on 'Test' should result in default action to be performed, and that's how it is up to 1.3.5. In 1.3.6 and above nothing happenes instead - I can see white screen only. Clicking on first three links works as it should.

[gkalpak]

It seems to work for me with v1.3.6. Also tested with v1.3.15 and v1.4.0-rc.0 and works as expected.

@machacz, it might be something else. Could you provide a live reproduction of the issue ?

[machacz]

http://angular.softnauts.com/szablony_routingi/index.html

Click on Test once, clik on other link, click on Test again.

[gkalpak]

There seems to be indeed some problem here.

I can't get to the root of the problem - that $location stuff did always scare me - but I fiddled around, so here is some additional info for any brave soul willing to tackle it:

Known facts about the issue:

• It affects versions v1.3.6 - latest (v1.3.15) and 1.4.0-beta.0 - latest (v1.4.0).
  v1.3.5 works fine.
• It is related to links with "regular" href. By "regular", I mean not hash-only links, such as href="#/...".
• It is related to links that are inside the $rootElement.
  For links outside of the $rootElement, everything works as expected (probably because the page is reloaded on every click).
• It happens when clicking a link that points to the current URL (including the query part) with no hash or an empty hash. E.g., while on http://example.com/index.html?test#/some/route, clicking on a link with href="index.html?test" will cause the issue.

---

Should anyone be interested, the issue can be reproduced in this codepen with the following steps:

1. Click on 'Test'.
2. Wait for the page to (re-)load.
3. Click on 'Test' again.

Expected behaviour:
Be redirected to the fallback route (/one/123/) (or at least stay there, since we are already on that route).

Observed behaviour:
Seems like we get redirected to the otherwise('/one/123/') route and stay there (as if it was a normal route, without redirection). (I am not 100% sure though.)

After step (3), clicking on the link again seems to have no effect (no change in location or route).

---

In order to gain some insight on what's going on, I tried logging the $location- and $route-related events (which can be seen in section Log entries in reverse chronological order).
The logs reported during step (3), seem kind of "suspicious" (or at least "unexpected").
Here they are (in chronological order):

#	Event-type	From	To
1	$routeChangeStart	/one/123/	REDIRECT_TO: /one/123/
2	$locationChangeStart	index.html?test=abc#/one/123/	index.html?test=abc
3	$locationChangeSuccess	index.html?test=abc#/one/123/	index.html?test=abc
4	$routeChangeStart	REDIRECT_TO: /one/123/	REDIRECT_TO: /one/123/
5	$locationChangeStart	index.html?test=abc#/one/123/	index.html?test=abc#
6	$routeChangeSuccess	/one/123/	REDIRECT_TO: /one/123/

The 4th entry seems particularly odd. I would expect a $routeChangeSuccess event (from /one/123/ to REDIRECT_TO: /one/123/) followed by a redirection to /one/123/.
Instead of that, we get a new $routeChangeStart event from REDIRECT_TO: /one/123/ to REDIRECT_TO: /one/123/ !? (Same 'from' and 'to' and both are routes with redirection.)

_{Note:
REDIRECT_TO: /one/123/ means "a route that has redirectTo: '/one/123/'".
As per $routeProvider's configuration, only the otherwise route contains such a redirection.}

---

Sorry for the long post. Let's hope it will be helpful to someone 😄

[gkalpak]

List of commits between v1.3.5 and v1.3.6 (for easy reference).

[richardTowers]

This also appears to cause <a href=#> links to break the route (you get <!-- ngView: undefined --> instead of the otherwise route). Here's a JSBin which reproduces the issue:

http://jsbin.com/momidogike/1/edit?html,js,output

I had a look at the commits in @gkalpak's list above and I think the problematic one is 10ac594. Reverting this commit appears to resolve the issue (JSBin output with patched Angular version - http://output.jsbin.com/mapizutoco/1#/)

[gkalpak]

I can confirm that using @richardTowers's patched version, fixes the original issue as well.

[lgalfaso]

to @petebacondarwin that is the $location daredevil

[petebacondarwin]

I believe that the reason that this does not "fail" in 1.3.5 is that the browser was always doing a full reload when we go to the Test3 route. You can see this happening if you run the CodePen with 1.3.5.

After the 10ac594 commit we no longer reload when only the hash is removed from the url and so it appears that we can now see this issue.

I would argue that the issue existed before too but that it was not apparent due to the reload hiding it.

[gkalpak]

This seems to have been fixed since at least 1.5.0: Updated pen
Closing...

_{(Please re-open if you still see the issue.)}

code.angularjs.org/1.5.6