Infinite digest loop occurring on first run of app when running grunt server #10423

jaredwilli · 2014-12-11T18:25:19Z

I tried to update my app to use 1.3.6 but when I do for some reason an infinite digest loop happens when I run grunt server and the app opens in the browser. It appears to redirect in the url bar over and over before it shows anything until finally it shows the page. Looking at the console I can see there are several errors for this.

Error: [$rootScope:infdig] 10 $digest() iterations reached. Aborting!
Watchers fired in the last 5 iterations: []
http://errors.angularjs.org/1.3.6/$rootScope/infdig?p0=10&p1=%5B%5D
    at http://localhost:9003/bower_components/angular/angular.js:63:12
    at Scope.$digest (http://localhost:9003/bower_components/angular/angular.js:14233:19)
    at Scope.$apply (http://localhost:9003/bower_components/angular/angular.js:14457:24)
    at bootstrapApply (http://localhost:9003/bower_components/angular/angular.js:1441:15)
    at Object.invoke (http://localhost:9003/bower_components/angular/angular.js:4169:17)
    at doBootstrap (http://localhost:9003/bower_components/angular/angular.js:1439:14)
    at bootstrap (http://localhost:9003/bower_components/angular/angular.js:1459:12)
    at angularInit (http://localhost:9003/bower_components/angular/angular.js:1353:5)
    at HTMLDocument.<anonymous> (http://localhost:9003/bower_components/angular/angular.js:25995:5)
    at fire (http://localhost:9003/bower_components/jquery/dist/jquery.js:3073:30)

When I refresh the page though, it doesn't happen. Only on the first run of the app.

The last version of angular that it doesn't do this in is 1.3.3.

The text was updated successfully, but these errors were encountered:

jaredwilli · 2014-12-11T18:26:14Z

Could be related to this issue angular-ui/ui-router#1616

caitp · 2014-12-11T18:28:18Z

ping @petebacondarwin

caitp · 2014-12-11T18:29:11Z

tentatively moving this to 1.3.8 but I don't expect it will be fixed immediately --- I think this is a duplicate issue too, lemme find the other

petebacondarwin · 2014-12-11T18:37:31Z

@jared will can you create a reproduction to demonstrate this?

jaredwilli · 2014-12-11T21:05:30Z

@petebacondarwin I have been trying to but unsuccessfully so far.

petebacondarwin · 2014-12-11T22:10:27Z

I suspect it is related to the $location rewriting of the path. What is you $location config? Are you using HTML5Mode?

m3kka · 2014-12-12T14:38:59Z

I think that my issue is somehow related #10405

The problem seems to involve the way $location deals with hashbang URLs.

jaredwilli · 2014-12-12T16:58:02Z

I am not using HTML5Mode no.

therajumandapati · 2015-01-21T06:49:07Z

@jaredwilli Can you share the code somehow ? If you can't do Plnkr, how about bundling your code and shipping it to me ?

Because I had the same problem some time ago, but unfortunately I lost the code. I'll try to reproduce this.

Narretz · 2015-04-20T18:38:36Z

I have put this into the Icebox since there is no reproduction and there is no one else experiencing this problem.

gkalpak · 2015-05-29T19:13:41Z

I think I was able to reproduce it (it's a much broader usecase - nothing to do with grunt server).

Basically, (I think) it happens when you have an empty $location#path and try to set a $location#hash during the initial bootstrap apply (e.g. in a run block, or during the instantiation of a controller).

Live reproduction

This is happening since v1.3.6 (and up to at least v1.4.0) and the problem is (afaict) in ng/browser.js on this line:

location.hash = getHash(url);

This is what happens:

Initial state:
- location.href === 'http://example.com/index.html'
- $location.path() === ''
- $location.hash() === ''
Action:
- $location.hash('foo')
Results into:
- $location.url() === '##foo' <--- inserts empty path
- $location.absUrl() === 'http://example.com/index.html##test'
In turn results into:
- location.hash = getHash('http://example.com/index.html##test') (see ng/browser.js)

Here is where the issue starts:

getHash() looks for the first # (if any) and returns the substring of the URL starting right after the first # (in this case, it will return #test). So, by calling location.hash = '#test' we really want to have .../index.html##test (notice the double #).
Unfortuntely, (at least on Chrome/FF/IE11 that I tried) location.hash tries to be smart and handle values both with and without the leading #. I.e. location.hash = 'foo' is equivalent to location.hash = '#foo' and both will result into .../index.html#foo. (Essentially, in the former case it adds the # automatically since it was missing, but in the latter case it doesn't add a #, because it thinks it's already there.)

(Assuming it works the same way in the rest of the supported browsers), the fix should be simple:

Just keep the leading # when setting location.hash. I.e. change getHash()'s implementation like this:

function getHash(url) {
  var index = url.indexOf('#');
  //return index === -1 ? '' : url.substr(index + 1);
  return index === -1 ? '' : url.substr(index);
}

/cc @petebacondarwin (since you are currently working on $location issues)

petebacondarwin · 2015-06-15T09:16:54Z

@jaredwilli and @gkalpak - can you see if 91b6022 fixed this?

petebacondarwin · 2015-06-15T09:20:00Z

I see that it doesn't on the live reproduction.

jaredwilli · 2015-06-15T13:49:52Z

I no longer have access to the code base that I was seeing this issue with. I have a different job now so can't test if this works.

… no hashPrefix The `window.location.hash' setter will strip of a single leading hash character if it exists from the fragment before joining the fragment value to the href with a new hash character. This meant that if we want the fragment to lead with a hash character, we must do `window.location.hash = '##test'` to ensure that the first hash character in the fragment is not lost. The `$location.hash` setter works differently and assumes that the value passed is the the full fragment, i.e. it does not attempt to strip off a single leading hash character. Previously, if you called, `$location.hash('#test')`, the leading hash was being stripped and the resulting url fragment did not contain this hash: `$location.hash()`, then became 'test' rather than `#test`, which led to an infinite digest. Closes angular#10423

petebacondarwin · 2015-06-17T10:35:21Z

I have a fix for this, using @gkalpak's suggestion. Please can you review?

gkalpak · 2015-06-17T12:31:58Z

#12145 seems to fix my live reproduction scenario.

… no hashPrefix The `window.location.hash' setter will strip of a single leading hash character if it exists from the fragment before joining the fragment value to the href with a new hash character. This meant that if we want the fragment to lead with a hash character, we must do `window.location.hash = '##test'` to ensure that the first hash character in the fragment is not lost. The `$location.hash` setter works differently and assumes that the value passed is the the full fragment, i.e. it does not attempt to strip off a single leading hash character. Previously, if you called, `$location.hash('#test')`, the leading hash was being stripped and the resulting url fragment did not contain this hash: `$location.hash()`, then became 'test' rather than `#test`, which led to an infinite digest. Closes angular#10423 Closes angular#12145

… no hashPrefix The `window.location.hash' setter will strip of a single leading hash character if it exists from the fragment before joining the fragment value to the href with a new hash character. This meant that if we want the fragment to lead with a hash character, we must do `window.location.hash = '##test'` to ensure that the first hash character in the fragment is not lost. The `$location.hash` setter works differently and assumes that the value passed is the the full fragment, i.e. it does not attempt to strip off a single leading hash character. Previously, if you called, `$location.hash('#test')`, the leading hash was being stripped and the resulting url fragment did not contain this hash: `$location.hash()`, then became 'test' rather than `#test`, which led to an infinite digest. Closes #10423 Closes #12145

… no hashPrefix The `window.location.hash' setter will strip of a single leading hash character if it exists from the fragment before joining the fragment value to the href with a new hash character. This meant that if we want the fragment to lead with a hash character, we must do `window.location.hash = '##test'` to ensure that the first hash character in the fragment is not lost. The `$location.hash` setter works differently and assumes that the value passed is the the full fragment, i.e. it does not attempt to strip off a single leading hash character. Previously, if you called, `$location.hash('#test')`, the leading hash was being stripped and the resulting url fragment did not contain this hash: `$location.hash()`, then became 'test' rather than `#test`, which led to an infinite digest. Closes angular#10423 Closes angular#12145

caitp added component: $location type: bug severity: broken expected use severity: regression labels Dec 11, 2014

caitp added this to the 1.3.8 milestone Dec 11, 2014

btford modified the milestones: 1.3.8, 1.3.9 Dec 19, 2014

petebacondarwin modified the milestones: 1.4.0-beta.0, 1.4.0-beta.1 / 1.3.10 Jan 15, 2015

pkozlowski-opensource modified the milestones: 1.4.0-beta.1 / 1.3.10, 1.4.0-beta.2 / 1.3.11 Jan 20, 2015

caitp modified the milestones: 1.4.0-beta.2 / 1.3.11, 1.4.0-beta.3 / 1.3.12 Jan 27, 2015

petebacondarwin modified the milestones: 1.4.0-beta.6 / 1.3.15, 1.4.0-beta.7 / 1.3.16 Mar 17, 2015

matsko modified the milestones: 1.4.0-beta.7 / 1.3.16, 1.4.0-rc.1 Apr 10, 2015

Narretz modified the milestones: Ice Box, 1.4.0-rc.1 Apr 20, 2015

petebacondarwin self-assigned this May 29, 2015

petebacondarwin modified the milestones: 1.4.1, Ice Box May 29, 2015

petebacondarwin modified the milestones: 1.4.1, 1.4.2 Jun 16, 2015

petebacondarwin mentioned this issue Jun 17, 2015

fix($browser): prevent infinite digest if changing hash when there is no hashPrefix #12145

Merged

petebacondarwin closed this as completed in #12145 Jun 17, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Infinite digest loop occurring on first run of app when running grunt server #10423

Infinite digest loop occurring on first run of app when running grunt server #10423

jaredwilli commented Dec 11, 2014

jaredwilli commented Dec 11, 2014

caitp commented Dec 11, 2014

caitp commented Dec 11, 2014

petebacondarwin commented Dec 11, 2014

jaredwilli commented Dec 11, 2014

petebacondarwin commented Dec 11, 2014

m3kka commented Dec 12, 2014

jaredwilli commented Dec 12, 2014

therajumandapati commented Jan 21, 2015

Narretz commented Apr 20, 2015

gkalpak commented May 29, 2015

petebacondarwin commented Jun 15, 2015

petebacondarwin commented Jun 15, 2015

jaredwilli commented Jun 15, 2015

petebacondarwin commented Jun 17, 2015

gkalpak commented Jun 17, 2015

Infinite digest loop occurring on first run of app when running grunt server #10423

Infinite digest loop occurring on first run of app when running grunt server #10423

Comments

jaredwilli commented Dec 11, 2014

jaredwilli commented Dec 11, 2014

caitp commented Dec 11, 2014

caitp commented Dec 11, 2014

petebacondarwin commented Dec 11, 2014

jaredwilli commented Dec 11, 2014

petebacondarwin commented Dec 11, 2014

m3kka commented Dec 12, 2014

jaredwilli commented Dec 12, 2014

therajumandapati commented Jan 21, 2015

Narretz commented Apr 20, 2015

gkalpak commented May 29, 2015

petebacondarwin commented Jun 15, 2015

petebacondarwin commented Jun 15, 2015

jaredwilli commented Jun 15, 2015

petebacondarwin commented Jun 17, 2015

gkalpak commented Jun 17, 2015