Bug: certain usage of $location causes infinite digest loop #12168

Activity

1. robmazan commented on Jun 19, 2015

   

   robmazan

   on Jun 19, 2015

   More actions

   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?
2. robmazan commented on Jun 19, 2015

   

   robmazan

   on Jun 19, 2015

   More actions

   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)
3. robmazan commented on Jun 19, 2015

   

   robmazan

   on Jun 19, 2015

   More actions

   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?
4. robmazan commented on Jun 19, 2015

   

   robmazan

   on Jun 19, 2015

   More actions

   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 :) ).
5. robmazan commented on Jun 19, 2015

   

   robmazan

   on Jun 19, 2015

   More actions

   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.
6. Narretz

   added

   type: bug

   component: $location

   on Jun 19, 2015
7. Narretz

   added this to the Ice Box milestone on Jun 19, 2015
8. robmazan commented on Jun 22, 2015

   

   robmazan

   on Jun 22, 2015

   More actions

   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.
9. gustavokloh commented on Jun 30, 2015

   

   gustavokloh

   on Jun 30, 2015

   More actions

   Returning the history.replaceState() not solve?

   Or is there some other reason to maintain location.replace()?
10. robmazan commented on Jul 1, 2015

    

    robmazan

    on Jul 1, 2015

    More actions

    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. :)
11. Narretz

    added

    frequency: low

    severity: broken expected use

    on Aug 4, 2015
12. gkalpak commented on Jan 4, 2017

    

    gkalpak

    on Jan 4, 2017

    Member

    More actions

    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.
13. gkalpak

    closed this as completedon Jan 4, 2017