Bug: certain usage of $location causes infinite digest loop

[dzmitry-kankalovich]

Related to #9629

Actual for angular 1.3.16

Using $location to set search param to null and then invoking $location.replace() causing infite digest loop.

See example here: http://plnkr.co/edit/udQ8rwDM6TJ3bsD3182l?p=preview

[robmazan]

Seems like the location.replace() is not happening immediately, but after a short time period, that is enough to cause infinite digest, as it is detected as a location change on each check.

I wonder if checking URL change against the actual URL (instead of lastBrowserUrl) would cause any issues?

[robmazan]

Or it can be solved by saving the actual URL (that should be there) and returning that instead of reading location.href directly. (I'm checking if this works now)

[robmazan]

Found a working solution that is similar to the reloadLocation exception, but taking a closer look revealed that when the only search param is reset in the example above ($location.search('some_param', null);) then the page is getting reloaded as stripping the # from the end of the URL makes the browser (Chrome in my case) thinking that the URL changed and it needs to load the "new" page. The infinite digest is happening right before the page is getting reloaded.

What do you think about making sure that once the # got in the URL making sure that it won't get stripped later?

[robmazan]

This issue seems to be present since v1.2.27. Running with v1.2.26 is not triggering infinite digest / page reload (though I'm not certain any more what URL change is causing a page reload any more :) ).

[robmazan]

Ok, so that specific change introduced the infinite digest in this setup: v1.2.26...v1.2.27#diff-ab8fe92910b19f1815d419aead809672R171

Removing the condition solves the infinite digest issue, but the page is still reloading... That's how far I could get for now. I hope I can find some time next week to pick up investigating.

[robmazan]

One more detail:

In v1.2.26 the code hits that line: v1.2.26...v1.2.27#diff-ab8fe92910b19f1815d419aead809672L158

While in v1.2.27 hits that one: v1.2.26...v1.2.27#diff-ab8fe92910b19f1815d419aead809672R175

So a history.replaceState() call got accidentally replaced with a location.replace() - that's the cause of the reloading.

[gustavokloh]

Returning the history.replaceState() not solve?

Or is there some other reason to maintain location.replace()?

[robmazan]

I suspect it has to do something with this comment:

angular.js/src/ng/browser.js

Lines 159 to 162 in 17d8a52

	// Don't use history API if only the hash changed
	// due to a bug in IE10/IE11 which leads
	// to not firing a `hashchange` nor `popstate` event
	// in some cases (see #9143).

I had no time to setup this specific case locally and experiment with it, but it's on my list. :)

[gkalpak]

I can't reproduce this any more on v1.5.10/v1.6.1. It was likely fixed at some point.
If this is still an issue, pleae open a new bug report with an updated reproduction.