$location.hash('') causes infinite digest loop #9635
Comments
jdkanani
changed the title
|
Possibly same bug as #9629 |
|
Note this is not related to html5Mode, (which can be seen in the repro) |
|
@caitp Yes. of course. My mistake. |
|
I looked into code and I think bug is the effect of commit 0656484
Meanwhile at $locationWatch, Result: It throws an error and causes page refresh as we experienced. I guess it will also fix bug #9629 |
|
the "bug" in the repro is pretty simple, it's an infinite loop. not angular's fault there --- but maybe its weird to chang location when search/hash changes |
|
I agree. Infinite loop is not angular's fault. But Solution is to change @caitp @tbosch @IgorMinar Any suggestions? |
|
well it's legacy mode, can't really rely on the history api existing until we forget IE9 exists =( |
|
😞 I understand. Anyway, thank you @caitp for your help. |
|
I think we can probably try to prevent $locationChangeXXX if it's just a hash or search query that changed, though. |
|
I don't know how to do that stuff as It took me two days to figure out this problem. :) Just a thought -- can't we use history API if hash/search is not available and Something like this(pseudo code): Changing |
I don't think this would be good, because they'll test their code on Chrome/Safari/FF or whatever, even though they need to support IE2.5 for whatever reason, and they'll think their code works, but in reality it crashes on IE9. It sucks, but I don't think we can really do that :( |
|
:( For now, I have changed my code to |
|
that seems like a weird way to fix it --- the real fix should basically be, make sure you don't start an infinite loop. |
|
I'm running into this issue too. I haven't looked into this in any great depth, but from what I can tell this is a problem in Angular and not a user-created infinite loop. I created a self-contained example (based on @jdkanani's plnkr) that shows that simply calling $location.hash('') will cause an infinite loop. @caitp sorry if I'm misunderstanding -- are you saying that this should never be done? Here's the example in a gist; I can't see hashes in plnkr and find that that adds to the confusion: |
|
My scenario: I want to open comment side modal on article when hash tag is - I cannot avoid infinite loop without setting non-empty hash. I would say this is very important issue with latest version of angular as it affects every angular application (with v1.3.0). Any suggestions? |
|
Here is simple repro steps:
|
|
@jdkanani +1 |
|
Running into this issue as well |
|
This is a valid bug (indeed regression) in Angular 1.3.x. |
By retaining a trailing `#` character in the URL we ensure that the browser does not attempt a reload, which in turn allows us to read the correct `location.href` value. Closes angular#9635
The url is the same whether or not there is an empty `#` marker at the end. This prevents unwanted calls to update the browser, since the browser is automatically applying an empty hash if necessary to prevent page reloads. Closes angular#9635
|
That commit does not fix this issue. Sorry |
|
@petebacondarwin I think we should use |
|
BTW, this issue also exists in 1.2.27 |
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
…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
…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
|
Take a look at #10308 - and see if this works for you. |
…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
…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
|
Still causes page reloading in HTML5 mode, if we loading page with empty hash at the end of URL. Looks like issue happens here: https://github.com/angular/angular.js/blob/master/src/ng/location.js#L882 For example I load |
|
@dtritus oh, I see. Could you please open a new issue for this one with a short description? Otherwise we might miss this one... |
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
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
Backported from e93710f The url is the same whether or not there is an empty `#` marker at the end. This prevents unwanted calls to update the browser, since the browser is automatically applying an empty hash if necessary to prevent page reloads. Closes angular#9635
Backported from e93710f The url is the same whether or not there is an empty `#` marker at the end. This prevents unwanted calls to update the browser, since the browser is automatically applying an empty hash if necessary to prevent page reloads. Closes angular#9635
Backported from 45f5dad The url is the same whether or not there is an empty `#` marker at the end. This prevents unwanted calls to update the browser, since the browser is automatically applying an empty hash if necessary to prevent page reloads. Closes angular#9635 Closes angular#10748
Angular version: v1.3.0
$location.hash('some_param')works fine but$location.hash('')gives infinite digest loop.Plunker link: http://embed.plnkr.co/mwtW1ZxDPDgEdj4PE7wj/preview
Related bug: #9629
Problem is any page with Angular v1.3.0 + empty hash, runs into this problem. Try this: https://docs.angularjs.org/api/ng/service/$location#
The text was updated successfully, but these errors were encountered: