$location injection causes / insertion after hash on page refresh when not in html5mode

[RichardLitt]

When not in html5mode, and using a URL of the format example.com/example#param=params, refreshing the page will automatically cause the URL to be rerouted to example.com/example#/param=params. In the particular case I am encountering, angular isn't being used for routing at all, and this functionality is undesired.

Related to #4608.

[francescozaia]

Seems that the cause of the issue here is:

// make sure path starts with '/';
  if (locationObj.$$path && locationObj.$$path.charAt(0) != '/') {
    locationObj.$$path = '/' + locationObj.$$path;
  }

in location.js. No time to investigate further more atm.

[skarev]

Getting the same problem.

[GaelMagnan]

I've taken a look at this issue, I've created a plunker: http://plnkr.co/edit/UVmB1EiZAQ0urL5HrVJ1?p=preview

It seems to me the problem is a bit more complex than just the 3 lines copied by francescozaia.

It seems to be the expected behavior.
In the tests you see:
it('should prefix path with forward-slash'
url.$$parse('http://host.com/base#path');
expect(url.absUrl()).toBe('http://host.com/base#/path');

So I've been tempering a bit with either:

• Changing the $$parse method to not remove the "#" and the $$compile not to force one back (wich is the reason the "#" still is present at the end.)
• Changing the parseAppUrl not to add a "/" to the path.
  But anyway i keep breaking the tests.

So i'm wondering if this is a real bug, and if it's fixable without a breaking change.

[francescozaia]

Yep, there is probably a lot of routing behaviours bound to those 3 lines indeed.

BTW, in my opinion this is a real bug, because fragments should work as they are part of HTML specs: http://www.w3.org/TR/html401/intro/intro.html#fragment-uri

[GaelMagnan]

I've actually gone through http://www.ietf.org/rfc/rfc3986.txt that according to https://docs.angularjs.org/guide/$location the location service follows.

I've noticed that :

3.3. Path

The path component contains data, usually organized in hierarchical
form, that, along with data in the non-hierarchical query component
(Section 3.4), serves to identify a resource within the scope of the
URI's scheme and naming authority (if any). The path is terminated
by the first question mark ("?") or number sign ("#") character, or
by the end of the URI.

Is not compatible with the test:

describe('HashbangUrl', function() {

beforeEach(function() {
url = new LocationHashbangUrl('http://www.server.org:1234/base', '#!');
url.$$parse('http://www.server.org:1234/base#!/path?a=b&c#hash');
});

it('should parse hashbang url into path and search', function() {
expect(url.protocol()).toBe('http');
expect(url.host()).toBe('www.server.org');
expect(url.port()).toBe(1234);
expect(url.path()).toBe('/path');
expect(url.search()).toEqual({a: 'b', c: true});
expect(url.hash()).toBe('hash');
});

Which clearly doesn't break the path on the first "#".
The following tests are not much more compliant. Not understanding why the Hashbang is implemented that way i'm giving up on fixing the problem without some explications.

Hope my research will help the next person taking on that issue.

[petebacondarwin]

Actually this is not a bug - it works as designed. Hashbang mode, as its names suggests should use a #! character to indicate the start of the route path. So in that case your URL would look like example.com/example#!#param=params.

Unfortunately we seem to have provided a default of just #, which is confusing for people, since to actually provide a real hash fragment you need to put two hash characters next to each other: example.com/example##param=params.

I think the best course of action is to change our default hash prefix to ! in 1.5 as a breaking change.

[Narretz]

The hashbang is going to be ! by default starting in 1.6