This repository has been archived by the owner on Apr 12, 2024. It is now read-only.
Bug: Setting $location.search() param value to null causes infinite digest loop #9629
Assignees
Milestone
Comments
|
Please link to the edit version of the plunker, the run links expire (this one has already) |
|
Here is the link: http://plnkr.co/edit/9G1gTEyH81eFyPm7mssr |
|
I believe this is a legitimate bug, unfortunately it's difficult to reproduce in a unit test, because |
petebacondarwin
added
severity: regression
needs: investigation
frequency: moderate
and removed
needs: more info
labels
|
There are some tricky bits to fix in order to get this fixed. Follow #9635 for more info |
petebacondarwin
added a commit
to petebacondarwin/angular.js
that referenced
this issue
Dec 3, 2014
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
…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
…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. |
|
It does! |
petebacondarwin
added a commit
to petebacondarwin/angular.js
that referenced
this issue
Dec 3, 2014
…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
…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
jeffbcross
pushed a commit
to jeffbcross/angular.js
that referenced
this issue
Dec 17, 2014
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
pushed a commit
to jeffbcross/angular.js
that referenced
this issue
Dec 17, 2014
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
|
@petebacondarwin Hi, looks like bug was fixed only partially. Check this plunkr (on basis of @Antontelesh one): http://plnkr.co/edit/udQ8rwDM6TJ3bsD3182l?p=preview . Simply add |
|
@dzmitry-kankalovich - thanks for spotting this. Could you open a new issue for this so that we can track it? |
|
@petebacondarwin no problem, done. #12168 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The bug occures only in new 1.3.0 version of Angular.
When I use
$location.search('some_param', 'value')everything works fine.But when I then use
$location.search('some_param', null)to clear that search param, Angular falls into infinite digest loop.See plunkr for example.
The text was updated successfully, but these errors were encountered: