This repository was archived by the owner on Apr 12, 2024. It is now read-only.
fix($location/$browser): prevent infinite digests when only modifying the hash of a URL #10308
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
|
CLAs look good, thanks! |
petebacondarwin
force-pushed
the
empty-hash-fix-3
branch
from
4f6b4a9 to
000185b
Compare
This was referenced Dec 3, 2014
| hashPrefix); | ||
| var withoutHashUrl; | ||
|
|
||
| if (withoutBaseUrl.charAt(0) == '#') { |
There was a problem hiding this comment.
It was cut and paste from the original :-( :-(
…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
force-pushed
the
empty-hash-fix-3
branch
from
000185b to
e056f85
Compare
|
LGTM |
petebacondarwin
added a commit
that referenced
this pull request
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 pull request
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 pull request
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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.