| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit cad717b1171affc3d540cea372576c70b0cb2295.
This change causes regressions in existing code and after closer inspection
I realized that it is trying to fix an issue that is should not be considered
a valid issue.
The location service was designed to work against either "hash" part of the
window.location when in the hashbang mode or full url when in the html5 mode.
This change tries to merge the two modes partially, which is not right. One
reason for this is that the search part of window.location can't be modified
while in the hashbang mode (a browser limitation), so with this change part
of the search object should be immutable and read-only which will only cause
more confusion.
Relates to #5964
|
|
Before this fix, search queries in hashbang mode were ignored if the hash was not present in the
url. This patch corrects this by ensuring that the search query is available to be parsed by
urlResolve when the hashbang is not present.
Closes #5964
|
|
|
|
|
|
|
|
It is problematic to use {@link} tags with external links because the
markdown parser converts them to links for us before we parse the @links.
This means that the following tag:
```
{@link http://www.google.com Google}
```
get converted to:
```
{@link <a href="http://www.google.com/"></a> Google}
```
Our {@link} parser then converts this to:
```
<a href="<a"><</a>href="http://www.google.com/"></a> Google}
```
which is clearly a mess. The best solution is not to use {@link} tags
for external links and just use the standard markdown syntax:
```
[Google](http://www.google.com)
```
In the long run, we could look into configuring or modifying `marked` not
to convert these external links or we could provide a "pre-parser"
processor that dealt with such links before `marked` gets its hands on it.
|
|
|
|
Previously missing the methods_ prefix.
Closes #5798
|
|
Closes #5717
|
|
This reverts commit 63cd873fef3207deef30c7a7ed66f4b8f647dc12.
The change breaks existing tests of Google apps. The problem is that
while we tried to avoid adding #/ to window.location.href unnecessarily
we failed doing so. Likely because by setting $path, at some point
(during a digest) we try to check if $location changed and we mistake the
default '/' with an explicit settign of the path via the `path()` method.
This results in us writing the url with '#/' into $browser.url() which updates
the window.location by adding "#/" to the url - something we tried to avoid
in the first place.
I'll reopen PR #5712.
|
|
Before this change, on the root of the application, $location.path() would return
the empty string. Following this change, it will always return a root of '/'.
Closes #5650
Closes #5712
|
|
triggered by the browser
Fixed inconsistency in $location.path() behaviour on the $locationChangeStart event when using
back/forward buttons in the browser or manually changing the url in the address bar.
$location.path() now returns the target url in these cases.
Closes #4989
Closes #5089
Closes #5118
Closes #5580
|
|
Before this fix, the xlink:href property of an SVG <a> element could not be parsed
on click, as the property is an SVGAnimatedString rather than a DOMString.
This patch parses the xlink:href's animVal into a DOMString in order to prevent
an `Object #<SVGAnimatedString> has no method 'indexOf'` exception from being thrown,
and also to update the location if necessary as expected.
Closes #5472
Closes #5198
Closes #5199
Closes #4098
Closes #1420
|
|
The urlResolve method was fixed to automatically remove the
volume label from path names to fix issues with the file
protocol on windows where $location.path() was returning
paths where the first segment would be the volume name,
such as "/C:/mypath". See #4942 and #4928
However, the solution was specific to the $location non-
HTML5 mode, and was implemented at a lower level of
abstraction than it should have been. This refactor moves
the fix to inside of the LocationHashBangUrl $$parse method.
Closes #5041
|
|
Prior to this fix, the urlResolve method would automatically
strip the first segment of a path if the segment ends in a colon.
This was to correct undesired behavior in the $location service
using the file protocol on windows in multiple browsers (see #4680).
However, there could be cases where users intentionally
have first path segments that end in a colon
(although this conflicts with section 3.3 of rfc3986).
The solution to this problem is an extra check to make sure
the first path segment of the input url does not end with a colon,
to make sure we're only removing undesired path segments.
Fixes #4939
|
|
search() supports an array for paramValue, but this is not described in the docs.
|
|
Closes #1569
Closes #4446
|
|
|
|
The location service, and other portions of the application,
were relying on a complicated regular expression to get parts of a URL.
But there is already a private urlUtils provider,
which relies on HTMLAnchorElement to provide this information,
and is suitable for most cases.
In order to make urlUtils more accessible in the absence of DI,
its methods were converted to standalone functions available globally.
The urlUtils.resolve method was renamed urlResolve,
and was refactored to only take 1 argument, url,
and not the 2nd "parse" boolean.
The method now always returns a parsed url.
All places in code which previously wanted a string instead of a parsed
url can now get the value from the href property of the returned object.
Tests were also added to ensure IPv6 addresses were handled correctly.
Closes #3533
Closes #2950
Closes #3249
|
|
|
|
|
|
|
|
|
|
we can never get to this state, so dropping the error
|
|
After a recent refactoring using $location in the default hashbang mode would result
in hash url being initialized unnecessarily in cases when the base url didn't end
with a slash.
for example http://localhost:8000/temp.html would get rewritten as
http://location:8000/temp.html#/temp.html by error.
|
|
|
|
|
|
parseKeyValue and toKeyValue can now handle duplicate values in the query.
```
?x=1&x=2 <-> {x:[1,2]}
```
The algorithm looks like:
1)parseKeyValue looks for presence of obj[key]
2)detects and replaces obj[key] with [obj[key],val]
3)then pushes more duplicates if necessary
4)toKeyValue decodes array correctly
5)(not changed)$location.search({param: 'key'}) still replaces if necessary
6)(not changed)$location.search({param: ['key1', 'key2']}) sets the url with duplicates
BREAKING CHANGE: Before this change:
- `parseKeyValue` only took the last key overwriting all the previous keys;
- `toKeyValue` joined the keys together in a comma delimited string.
This was deemed buggy behavior. If your server relied on this behavior
then either the server should be fixed or a simple serialization of
the array should be done on the client before passing it to $location.
|
|
With the recent refactoring of $location service we changed this behavior
resulting in a regression.
Previously we thought that html5 mode always required base[href]
to be set in order for urls to resolve properly. It turns out that
base[href] is problematic because it makes anchor urls (#foo) to
always resolve to the base url, which is almost always incorrect
and results in all anchors links and other anchor urls (e.g. svg
references) to be broken.
For this reason, we should now start recommending that people just
deploy to root context (/) and not set the base[href] when using
the html5 mode (push/pop history state).
If it's impossible to deploy to the root context then either all
urls in the app must be absolute or base[href] must be set with the
caveat that anchor urls in such app won't work.
Closes #2762
|
|
jQuery switched to a completely new event binding implementation as of
1.7.0, centering around on/off methods instead of previous bind/unbind.
This patch makes jqLite match this implementation while still supporting
previous bind/unbind methods.
|
|
|
|
- add toThrowNg matcher
|
|
|
|
|
|
|
|
Before $locationChangeStart event is not broadcast when pressing the back-button on the browser.
Closes #2109
|
|
|
|
Closes #1051
|
|
FirefoxOS uses special URLs like
app://{d0419af1-8b42-41c5-96f4-ef4179e52315}/index.html for packaged Apps.
Closes #2112
|
|
In situations where path() matched basepath and we needed to
convert from html5 url to hashbang url, the $location service
considered the url to be already rewritten, which resulted in
an error.
|
|
Closes #1111
|
|
When user clicks a link, $location needs to intercept this event. The <a> doesn't have to be target element of the DOM event, so it needs to traverse the DOM, to find first <a> parent.
If the target element was removed from DOM, during the same event, it would throw an exception. This fixes the issue.
Closes #1058
|
|
Closes #1051
|
|
This is a second fix for a regression that was introduced by 92a2e180.
The fix addresses scenarios when the $location service is configured with
a hash prefix.
Closes #1037
|
|
This is a fix for a regression that was introduced by 92a2e180
Closes #1037
|
|
|
|
we now have two types of namespaces:
- true namespace: angular.* - used for all global apis
- virtual namespace: ng.*, ngMock.*, ... - used for all DI modules
the virual namespaces have services under the second namespace level (e.g. ng.)
and filters and directives prefixed with filter: and directive: respectively
(e.g. ng.filter:orderBy, ng.directive:ngRepeat)
this simplifies urls and makes them a lot shorter while still avoiding name collisions
|
|
This allows location change cancelation
|
|
|
|
documentation used @return but parser expected
@returns, which made the generated documentation
incomplete.
|
