$location.state problems in 1.3.0-rc.5

[bukharin]

My application stores some data in history state object. Before rc.5 version I used history.replaceState method. Now I rewrite my code to use new API: $location.state(obj).replace()

For instance:

$rootScope.$on('$locationChangeSuccess', function() {
       if(!$location.state())
              $location.state(Math.random()).replace();
});

It seems works fine, but when I click 'back' browser button (popstate event) - after that application stops responding on any link clicks (routes does not changes).

After investigate the source code I found that condition at angular.js:10905 always falsy

if (initializing || oldUrl !== $location.absUrl() ||
          ($location.$$html5 && $sniffer.history && oldState !== $location.$$state)) {
...
}

oldState and $location.$$state are equals after user click on the link

This problem in Chrome and FF. IE11 throws an exception after bootstrap:

Error: [$rootScope:infdig] 10 $digest() iterations reached. Aborting!
Watchers fired in the last 5 iterations: []
http://errors.angularjs.org/1.3.0-rc.5/$rootScope/infdig?p0=10&p1=%5B%5D
   at Scope.prototype.$digest (https://localhost:44300/vendor/angularjs/angular.js:13731:13)
   at Scope.prototype.$apply (https://localhost:44300/vendor/angularjs/angular.js:13955:13)
   at bootstrapApply (https://localhost:44300/vendor/angularjs/angular.js:1486:9)
   at invoke (https://localhost:44300/vendor/angularjs/angular.js:4133:7)
   at doBootstrap (https://localhost:44300/vendor/angularjs/angular.js:1484:5)
   at bootstrap (https://localhost:44300/vendor/angularjs/angular.js:1504:5)
   at Global code (https://localhost:44300/scripts/base/app.js:100:1)
SCRIPT5022: [$rootScope:infdig] 10 $digest() iterations reached. Aborting!
Watchers fired in the last 5 iterations: []
http://errors.angularjs.org/1.3.0-rc.5/$rootScope/infdig?p0=10&p1=%5B%5D

[IgorMinar]

@mzgol can you take a look at this?

[mgol]

From what I see the issue is caused by the fact that history.state might be a primitive, not an object. In case of objects, pressing the back button will give us a state object deep equal to the previous one at this point but referentially different which will work fine; it won't for primitives like number from Math.random() here.

I'll need to think how to bypass this issue.

@bukharin Can you confirm that if you don't use numbers as state objects but objects (try e.g. passing {number: Math.random()} instead of Math.random() the issue disappears?

[mgol]

Actually, I'm not sure what the issue is. What I mentioned above is true but I don't see how it can cause issues.

@bukharin could you post a minimal code example showing the problem so that I fully understand what's the issue? The check in location.js first checks for a URL so both URLs and states have to be identical for the if to evaluate to false; I need more context.

[mgol]

I see the IE11 issue in my app so I'll try to debug that first.

[mgol]

As for IE11, I'm taking my jaw from the floor... In this browser, the following:

history.pushState({a: 2}, 'a', 'b');
var o = history.state;
console.log(o === history.state);

prints false... O_o. This means the entire logic of comparing states referentially won't work and we have to find a different approach.

@IgorMinar I don't think I can fix it before Monday. I should've notice this before but $browser in location tests is mocked and obviously doesn't have this bug.

EDIT: I submitted this to IE bug tracker: https://connect.microsoft.com/IE/feedback/details/998728.

@bukharin Thanks for the report! It seems we actually have 2 bugs here; I'm focusing on the IE one now since it's more severe but I'd still love to get a test case to be able to fix it in Chrome/Firefox later.

[mgol]

Note to self: try to avoid the issue by caching history.state on popstate/hashchange and comparing to that instead of history.state.

EDIT: that idea probably won't work since:

history.pushState({a: 2}, 'a', 'b');
history.state === history.state; // false

It seems the object is deserialized on read so every read will get sth different.

[mgol]

@IgorMinar The only workaround I see is to attach the internal $$id property to every non-primitive history.state and compare that if the strict equality fails. Is it acceptable?

EDIT: we could also attach this $$id thing only in IE.