An option to have AngularJS leave the URL hash-fragment alone

[mhelvens]

The $locationProvider module 'hijacks' the hash-fragment of a URL. This is being done to encode paths for browsers that don't support the HTML5 history API (which is understandable and useful). For example, with html5Mode disabled:

• A given URL http://my.domain.com#my-hash is turned into http://my.domain.com/#/my-hash, and $location.hash() will be empty.

The problem is that the hash-fragment is still being hijacked when html5Mode is enabled and a modern browser is used... when there is no path in the URL. For example:

• A given URL http://my.domain.com#my-hash is turned into http://my.domain.com/my-hash, and $location.hash() will still be empty. The hash fragment in http://my.domain.com/path#my-hash, however, is left alone.

I'm not sure whether this is a bug or intentional behavior. But in either case, I would like an option to have AngularJS leave my hash fragment alone altogether.

[tbosch]

Hi,
you could just not use $location. If you open this URL, the hash stays as it was: http://jsfiddle.net/FA737/4/show/#asdf

However, if you use $location in a controller, ... it will rewrite the hash, e.g. http://jsfiddle.net/FA737/3/show/#asdf

So you still want to use $location but you want to use it just as a pass-through of window.location, without any changes, right?

Could you explain your use case a little bit more, what kind of app you want to build....

[mhelvens]

This issue is pretty much solved for me now (by help on Stackoverflow), but I'd like to give a complete response.

I'll admit that "not using $location" hadn't occurred to me. Merely accessing a variable and using getter methods probably shouldn't cause observable side-effects. I understand the reasoning in this case, but this behavior is obscurely documented. I'd propose a note in the 'What does it do' section.

I now discovered that if I use a non-empty hashPrefix, bare hash characters are left alone. This suffices for my purposes. Though perhaps the inconsistent behavior I pointed out in my description above (domain with vs. without path) may lead you to leave this issue open as a bug.