Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

Infinite digest when replacing $location.hash() #10228

Closed
pkaminski opened this issue Nov 26, 2014 · 6 comments
Closed

Infinite digest when replacing $location.hash() #10228

pkaminski opened this issue Nov 26, 2014 · 6 comments
Assignees
@petebacondarwin
Labels
component: $location type: bug
Milestone
1.3.6

Comments

@pkaminski
Copy link

This appears to be a regression in v1.2.27 probably caused by #9470 (@tbosch); v1.2.26 (and earlier, probably at least back to v1.2.24) does not exhibit the problem. The details:

I'm running $locationProvider in html5Mode. In a controller bound with ng-route I have the following code very near the top of the constructor:

  if ($location.hash()) {
    $rootScope.hash = $location.hash();
    $location.replace();
    $location.hash('');
    return;
  }

This is meant to squirrel away the hash and remove it from the URL, causing the controller to be reloaded. What ends up happening in v1.2.27 (in both Chrome 39 and Firefox 33.1.1) is that $browser.url() calls location.replace() but no longer sets reloadLocation because sameBase is true. However, location.href keeps returning the original URL with the hash, causing $locationWatch to spin and keep issuing $browser.url() calls, which are no-ops because lastBrowserUrl is already stripped of the hash. Then everything comes crashing down with an infinite digest error.

It's entirely possible that I'm doing something wrong, in which case I'd really appreciate a hint as to what that might be. Thanks!
@janv
Copy link

janv commented Nov 26, 2014

I am observing the same problem in 1.3.4

@pkozlowski-opensource
Copy link
Member

@pkaminski @janv there are couple of issues around replacing hash + page reload opened already so it would be good to have a minimal reproduce scenario just to make sure that we've got all of those fixed.

@pkozlowski-opensource pkozlowski-opensource added this to the 1.3.6 milestone Nov 26, 2014
@janv
Copy link

janv commented Nov 26, 2014

Yeah, this seems to be a duplicate of (or closely related to) at least #9635 and #9629

@janv
Copy link

janv commented Nov 26, 2014

@pkozlowski-opensource #9635 has a minimal reproduce scenario linked in a plunkr: http://embed.plnkr.co/mwtW1ZxDPDgEdj4PE7wj/preview

That one is Angular 1.3, here it is running 1.2.27: http://embed.plnkr.co/s9DM4wilD8UOefHHrVgd/preview

@pkozlowski-opensource
Copy link
Member

@janv thnx! Let's keep this one open till the #9635 is fixed but it is good to know that this is a duplicate.

@petebacondarwin petebacondarwin self-assigned this Dec 1, 2014
petebacondarwin added a commit to petebacondarwin/angular.js that referenced this issue Dec 3, 2014
@petebacondarwin
fix($browser): prevent infinite digests when clearing the hash of a url
408901e 
By using `location.hash` to update the current browser location when only
the hash has changed, we prevent the browser from attempting to reload.

Closes angular#9629
Closes angular#9635
Closes angular#10228
petebacondarwin added a commit to petebacondarwin/angular.js that referenced this issue Dec 3, 2014
@petebacondarwin
fix($location): allow hash fragments with hashPrefix in hash-bang loc…
4f6b4a9 
…ation urls

Previously if there was a hash fragment but no hashPrefix we would throw an error.
Now we assume that the hash-bang path is empty and that the hash is a valid fragment.

This prevents unnecessary exceptions where we clear the hashBang path, say by
navigating back to the base url, where the $browser leaves an empty hash symbol
on the URL to ensure there is no browser reload.

BREAKING CHANGE:

We no longer throw an `ihshprfx` error if the URL after the base path
contains only a hash fragment.  Previously, if the base URL was `http://abc.com/base/`
and the hashPrefix is `!` then trying to parse `http://abc.com/base/#some-fragment`
would have thrown an error. Now we simply assume it is a normal fragment and
that the path is empty, resulting `$location.absUrl() === "http://abc.com/base/#!/#some-fragment"`.

This should not break any applications, but you can no longer rely on receiving the
`ihshprfx` error for paths that have the syntax above. It is actually more similar
to what currently happens for invalid extra paths anyway:  If the base URL
and hashPrfix are set up as above, then `http://abc.com/base/other/path` does not
throw an error but just ignores the extra path: `http://abc.com/base`.

Closes angular#9629
Closes angular#9635
Closes angular#10228
petebacondarwin added a commit to petebacondarwin/angular.js that referenced this issue Dec 3, 2014
@petebacondarwin
fix($location): allow hash fragments with hashPrefix in hash-bang loc…
000185b 
…ation urls

Previously if there was a hash fragment but no hashPrefix we would throw an error.
Now we assume that the hash-bang path is empty and that the hash is a valid fragment.

This prevents unnecessary exceptions where we clear the hashBang path, say by
navigating back to the base url, where the $browser leaves an empty hash symbol
on the URL to ensure there is no browser reload.

BREAKING CHANGE:

We no longer throw an `ihshprfx` error if the URL after the base path
contains only a hash fragment.  Previously, if the base URL was `http://abc.com/base/`
and the hashPrefix is `!` then trying to parse `http://abc.com/base/#some-fragment`
would have thrown an error. Now we simply assume it is a normal fragment and
that the path is empty, resulting `$location.absUrl() === "http://abc.com/base/#!/#some-fragment"`.

This should not break any applications, but you can no longer rely on receiving the
`ihshprfx` error for paths that have the syntax above. It is actually more similar
to what currently happens for invalid extra paths anyway:  If the base URL
and hashPrfix are set up as above, then `http://abc.com/base/other/path` does not
throw an error but just ignores the extra path: `http://abc.com/base`.

Closes angular#9629
Closes angular#9635
Closes angular#10228
@petebacondarwin
Copy link
Contributor

Take a look at #10308 - and see if this works for you.

See http://plnkr.co/edit/v2s7sUrLmvJD5HPoGhR8?p=preview, which is using html5Mode

petebacondarwin added a commit to petebacondarwin/angular.js that referenced this issue Dec 3, 2014
@petebacondarwin
fix($location): allow hash fragments with hashPrefix in hash-bang loc…
e056f85 
…ation urls

Previously if there was a hash fragment but no hashPrefix we would throw an error.
Now we assume that the hash-bang path is empty and that the hash is a valid fragment.

This prevents unnecessary exceptions where we clear the hashBang path, say by
navigating back to the base url, where the $browser leaves an empty hash symbol
on the URL to ensure there is no browser reload.

BREAKING CHANGE:

We no longer throw an `ihshprfx` error if the URL after the base path
contains only a hash fragment.  Previously, if the base URL was `http://abc.com/base/`
and the hashPrefix is `!` then trying to parse `http://abc.com/base/#some-fragment`
would have thrown an error. Now we simply assume it is a normal fragment and
that the path is empty, resulting `$location.absUrl() === "http://abc.com/base/#!/#some-fragment"`.

This should not break any applications, but you can no longer rely on receiving the
`ihshprfx` error for paths that have the syntax above. It is actually more similar
to what currently happens for invalid extra paths anyway:  If the base URL
and hashPrfix are set up as above, then `http://abc.com/base/other/path` does not
throw an error but just ignores the extra path: `http://abc.com/base`.

Closes angular#9629
Closes angular#9635
Closes angular#10228
petebacondarwin added a commit that referenced this issue Dec 4, 2014
@petebacondarwin
fix($location): allow hash fragments with hashPrefix in hash-bang loc…
2dc34a9 
…ation urls

Previously if there was a hash fragment but no hashPrefix we would throw an error.
Now we assume that the hash-bang path is empty and that the hash is a valid fragment.

This prevents unnecessary exceptions where we clear the hashBang path, say by
navigating back to the base url, where the $browser leaves an empty hash symbol
on the URL to ensure there is no browser reload.

BREAKING CHANGE:

We no longer throw an `ihshprfx` error if the URL after the base path
contains only a hash fragment.  Previously, if the base URL was `http://abc.com/base/`
and the hashPrefix is `!` then trying to parse `http://abc.com/base/#some-fragment`
would have thrown an error. Now we simply assume it is a normal fragment and
that the path is empty, resulting `$location.absUrl() === "http://abc.com/base/#!/#some-fragment"`.

This should not break any applications, but you can no longer rely on receiving the
`ihshprfx` error for paths that have the syntax above. It is actually more similar
to what currently happens for invalid extra paths anyway:  If the base URL
and hashPrfix are set up as above, then `http://abc.com/base/other/path` does not
throw an error but just ignores the extra path: `http://abc.com/base`.

Closes #9629
Closes #9635
Closes #10228
Closes #10308
@dtritus dtritus mentioned this issue Dec 9, 2014
Closed
@calendee calendee mentioned this issue Dec 9, 2014
Closed
jeffbcross pushed a commit to jeffbcross/angular.js that referenced this issue Dec 17, 2014
@petebacondarwin @jeffbcross
fix($browser): prevent infinite digests when clearing the hash of a url
0076ddd 
By using `location.hash` to update the current browser location when only
the hash has changed, we prevent the browser from attempting to reload.

Closes angular#9629
Closes angular#9635
Closes angular#10228
Closes angular#10308
@jeffbcross jeffbcross mentioned this issue Dec 17, 2014
Merged
jeffbcross pushed a commit to jeffbcross/angular.js that referenced this issue Dec 17, 2014
@petebacondarwin @jeffbcross
fix($browser): prevent infinite digests when clearing the hash of a url
9845cee 
By using `location.hash` to update the current browser location when only
the hash has changed, we prevent the browser from attempting to reload.

Closes angular#9629
Closes angular#9635
Closes angular#10228
Closes angular#10308
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@petebacondarwin petebacondarwin

Labels
component: $location type: bug
Projects
None yet
Milestone
1.3.6
Development

No branches or pull requests
4 participants
@petebacondarwin @janv @pkozlowski-opensource @pkaminski