You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix($location): allow hash fragments with hashPrefix in hash-bang location 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`.
Closesangular#9629Closesangular#9635Closesangular#10228
0 commit comments