Should $location extract search params from before the #! ?

[bhollis]

When not in HTML5 mode, given a URL like this:

http://foo.com/?bar=baz

$location.search() produces an empty object, rather than { bar: 'baz' }.

I understand that it's looking only at the part of the URL following #!, but I'm wondering if that's really the correct way to go - it certainly makes it difficult to extract and use those query parameters (without using separate URL parsing code for window.location). Is this just not what $location is for? The docs say:

The $location service parses the URL in the browser address bar (based on the window.location) and makes the URL available to your application." which suggests it should parse the whole URL.

I'd also expect that given a URL like this, not in HTML5 mode:

http://foo.com/?bar=baz#!/?qux=quux

I'd expect $location.search() to be { bar: 'baz', qux: 'quux' } - the merged set of query parameters.

[caitp]

well if search isn't working in hashbang mode when there's no hashbang, that sounds like a bug. care to try and submit a patch? It would be good if you could show a jasmine test which fails without a fix first

[caitp]

Actually, this seems to be from urlResolve.js, where we give an anchor tag the url and get it to parse it for us. So I guess the browser isn't convinced there's a search string either, without the '#/'.... So are you saying that with html5Mode it works as you expect? because it would appear not to

[bhollis]

@caitp I'd be happy to write up a PR, but I need to wait for permission to sign the CLA and provide code to the project.

[caitp]

@bhollis it's okay, I've realized that we were not actually sending the urlResolve function the entire relative url, and am submitting a fix for this. It might actually make it to the release after all if we defer until tomorrow.

[bhollis]

Thanks, that's great!

[bhollis]

It looks like that fixes the first case, which is great. What do you think about the slightly weirder second example:

http://foo.com/?bar=baz#!/?qux=quux

Where there's both a search string before, and after the hash?

[caitp]

I'm not sure if that's a really valid URL... I'll have to see what people think about it. How are you coming up with a url like that in angular anyway?

[bhollis]

That one's theoretical, but I was assuming it was what would happen if I modified $location.search() in non-HTML5-mode after starting with a URL that had a query string.

[caitp]

If that does happen, I think that's a separate bug to look at. But we should really get a reproduction to be sure