Backbone history possible bug on a page with querystring #2075

fabiomcosta opened this Issue Jan 5, 2013 · 6 comments

3 participants


If you go to a page with any querystring, lets say:

And you try to navigate using router.navigate or Backbone.history.navigate to the same page without querystring it won't do that. In this case trying to navigate to /pathname/ won't do anything.

What happens is that on
this.fragment is equal to fragment so this.fragment is getting an incorrect value on history.start

I've created an example here:


Any ideas?
Am I doing something wrong?


It looks like you need to set the root property in your options, as the application isn't being served from the base domain.

If your application is not being served from the root url / of your domain, be sure to tell History where the root really is, as an option: Backbone.history.start({pushState: true, root: "/public/search/"})

Regarding the query string, @braddunbar is the guy to ask on this one, but I'm pretty sure that backbone ignores query parameters - from the change log for 0.9.9

For semantic and cross browser reasons, routes will now ignore search parameters. Routes like search?query=…&page=3 should become search/…/3.

So I believe that and are considered the same url. You may want to just call the function on the router directly, as opposed to trying to navigate to the route which you're already located at.


@tgriesser thank you very much! A lot of great information there, setting root solved my problem.
I still don't understand why search is ignored, it has valid use cases. For example, filters like discount and price range on a list of products, not to mention a lot of other use cases.

I understand the importance of "pretty-urls", but this shouldn't be forced by such a flexible framework as Backbone.
Also, what's the cross-browser issue related to this change?

I'm sorry if it looked like I'm being agressive. I'm not.


@fabiomcosta - it's not really an issue of pretty-urls, much more related to the cross browser issues - for some history on the query string issues you can see #891, #1624, and #2023.

Didn't seem agressive - I just didn't understand the question at first until looking at it again now. Glad you were able to get it sorted. Ideally you'd be doing most of your query filtering through the params in your ajax-GET requests, rather than in the actual browser url.

@tgriesser tgriesser closed this Jan 8, 2013

Hi @fabiomcosta! The problem is that support of hash based fragments requires that we ignore the query string. For instance, the url /foo#bar?baz=3 contains no query string, only a hash that looks like one. However, when considering a url like /foo?baz=4#bar?baz=3, there are potentially two values for baz. This becomes even more complex when transitioning from hash based routing to pushState routing. Which value to we use? Should we replace the real query string with the faux one? That approach is needlessly complex, especially considering that a path based url is more human readable anyway (/search/query/page vs. `search?query=...&page=...).

There are more reasons in the issues mentioned by @tgriesser above, especially #891. I hope that clears things up a bit. :)


OK cool, thank you guys for explaining everything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment