this ist my situation:
I've got a simple list with links that point to something like
now, when I click on the first link the correct page gets loaded. Going back to that list and clicking another link visits the first page again. I believe it has something to do with not changing the hash correctly. Could it be that the hash is somehow chached and only identifies the #somePage part and not the ?someId=2 part?
Thanks and greetings
Can you post a simplified test page using the latest build and specify step to reproduce and browser/device version info? Template here:
Look at the addressbar after clicking link one, going back and clicking link two. The address bar is pointing to #somePage?id=1.
Appears on the latest Chrome, Firefox and my Android 2.3 Browser.
I'm having this exact same issue(w/rc2), and so are a few others:
Can you test this with pushState disabled? I know that some browsers get wonky with forward/back navigation and our pushState code because there is some inconsistency in when popstate is fired across browsers.
Thanks for the suggestion - sadly it didn't fix it. We are doing our testing and development using desktop versions of chrome and firefox, both of which have the same broken URL behavior. This also exhibits similar issues when using the jquery mobile provided back button, i.e. it goes back to the wrong page.
Thanks, we'll prioritize this.
@celer and @StevePo
We don't currently support query parameters as part of the hash fragment, though this is something that's been discussed frequently internally and is on the feature request list.
For clarity you'll note in the rfc that the fragment is "is indicated by the presence of a number sign ("#") character and terminated by the end of the URI". So if you are looking to provide those parameters as part of a request to a server they need to be moved before the fragment.
Has been tracking this closely and may have corrections/more to add.
As @johnbender mentioned, we do not officially support query param passing to internal/embedded pages. When jQuery Mobile comes across "#somePage?someId=1" it passes it to jQuery core, which seems to interpret that as "#somePage" so it locates the internal page div, but then it tags it with a data-url of "#somePage?someId=1", which is why subsequent calls to "#somePage?someId=2" find the same div. The reason why it always displays "#somePage?someId=1" is because jQuery Mobile uses the data-url on the div which only gets set once.
I've seen enough of these internal page param requests that I went and wrote a plugin for folks. You can find it here:
You can take it, modify it, and bend it to your will. There was also a similar discussion in issue #450 where someone else ended up writing a different plugin for use with backbone.js:
My version is just the barebones necessary to get this to work.
Thanks for the feedback! We're trying to provide those parameters to the client side code. I guess perhaps are using jQuery Mobile in a way that was not intended.
Lets say were building a 100% client side app using phone gap, that has no server side component and uses localStorage / lawn chair for storage of data.
Our hope is that we could use the URL to pass parameters between client side pages so that we retain bookmark ability.
For example, lets say I have a simple project, for example an addressbook.
And I have two jQuery mobile pages which are fed from localStorage / etc.
#list - show a list of all the addresses
Both of these pages would be populated by jQuery on the fly using localStorage. Again our goal was to retain bookmark ability of these pages, and use the URL to pass the page parameters.
We were just trying to cheat a little bit - what is the recommended way of passing data parameters back and forth between client side generated pages?
I think that if you use one of the plugin above, then it's a fine way to go. Well look at how much we want to pull in in a future version.
I'm going to keep this open for now, but this is pretty much a feature request. I also edited the title for clarity.
I these plugins are not fully compatible with 1.1.0RC1
I have been working with the dev of jquery.mobile.router
This is now and an issue with or without the plugins.
Discussion about jqmr here:
Patching my 1.1.1 release with flodev's patch fixes the problem for me.
Still a big issue with jqm 1.2
First of all, from the beginning we have been clear about query params not being supported, when using jQuery Mobile's AJAX navigation. There has been a change of behaviour between 1.2 (error) and 1.3 (stripping). We decided that if we make changes again it should be a permanent solution, so we don't keep changing things each version. We didn't have enough time to do this for 1.4 so it has to wait until 1.5.
From the 1.4 changelog: "Deprecated current behaviour of stripping query strings from hashes. Starting in 1.5 we’ll be following spec on hashes and provide a hook to handle custom navigation."
In the meantime we will look into a workaround that can be used with 1.3 and 1.4. When there is one we will inform you about it in a comment on this ticket.
After discussion we are not going to support query params an as @uGoMobi above indicated instead going to allow any valid id and not have any special handling. Since we are going another direction with this im going to go ahead and close.
@StevePo @toddparker @celer @johnbender @jblas @raldred @rjsteinert @dotnetwise @uGoMobi @arschmitz
If anybody still cares about this, I created a simple plug-in which allows you to pass and maintain URL parameters within embedded jQuery Mobile pages for the multi-page template. It works well but could probably use some touch-ups and improvements...which I'll do if people ask for them & time permits..or people can also contribute. You can find the plug-in here..
I still care. I have to say I hope that in a future version this gets implemented into the main distribution. As previously explained, a tag <a href="#foo?bar=baz">link</a naviagtes only to #foo, which to a newcomer would be unexpected behavior. With the ride of "deep-linking" in mobile applications, it makes more sense to leave the hash as navigated rather than modifying it.