Use history.pushState in our page loading logic

[scottjehl]

I ran some tests this morning for pushState support (see new test added to jQuery.support.js).

Looks like we might be able to use it in a few places (at least iPhone, iPad, lastest BB, desktop), to combat our non-js bookmarking issue.

!!history.pushState returns:

iPhone w/ iOS4: TRUE
Blackberry 6 (Torch device): TRUE
Stock iPad: FALSE (iPad with update should be TRUE)
Palm Pixi: FALSE
HTC Incredible w/ Android (not sure which version): FALSE
Windows Mobile (not sure which version): FALSE

Chrome 6 mac desktop: TRUE
Firefox 3.6: FALSE
Firefox 4: TRUE (unable to verify right now)
Safari 5 mac desktop: TRUE
Opera 10 desktop: FALSE

[scottjehl]

Here's a patch for a very rough (but somewhat functional) implementation using pushState where supported:
http://filamentgroup.com/clients/jq-mobile/diffs/jQuery.mobile.js.diff

[scottjehl]

There's a patch for this above. It works okay but it's not fully built, but do you guys think this is important for Alpha? If not, I'll untag it.

[scottjehl]

Updated the patch. Seems to work for most page transitions and deep links but it's not fully baked yet:
http://filamentgroup.com/clients/jq-mobile/diffs/jQuery.mobile.js.diff

[scottjehl]

New "pushstate" branch has my first-pass at making this work.
Seems to work quite well, check out the demo in a pushState-supporting browser, like Chrome or any of the browsers that are listed as TRUE above.

Demo here:
http://filamentgroup.com/examples/jqm-pushstate/docs/about/intro.html

branch here:
https://github.com/jquery/jquery-mobile/tree/pushstate

[jzaefferer]

I've updated the branch with latest changes from master and did some testing. As the results on iOS 4.2.x are pretty bad, I also did some more research on pushState support on iOS, but without any really useful results. It seems like no one really tried using pushState on iOS 4.2.x (and wrote about it in public). I documented some findings here anyway: http://wiki.jqueryui.com/w/page/12137953/History

[balupton]

Hey guys, would it be possible to use History.js for this? It aims to provide a cross-framework and cross-browser solution for the HTML5 History APIs. It's also my day job to work on it - so if it can be improved in anyway then please let me know and I'll attend to it right away. I'll be presenting at the Aloha Editor DevCon in February which several of the jQuery UI guys are attending - so could work with the team there?

So please do get in contact with me at contact@balupton.com skype via balupton or mobile via +61 4 3020 8061 as I'm committed to making this happen.

[petrbela]

Hi guys, what's the current status of this issue? I'm trying to overwrite the default jQM code and use History.js for handling the navigation in my project, but I'm sure it would be more useful if it became a standard part of the framework.

[scottjehl]

We're working on a refactor of navigation.js now, and once that's in, we plan to include pushState wherever supported.

[petrbela]

Great! Any estimation when it could be done?

[balupton]

@scottjehl how are you planning to solve the browser specific bugs with the HTML5 History API?

• History.js solves the following browser bugs:
  • HTML5 Browsers
    • Chrome 8 sometimes does not contain the correct state data when traversing back to the initial state
    • Safari 5, Safari iOS 4 and Firefox 3 and 4 do not fire the window.onhashchange event when the page is loaded with a hash
    • Safari 5 and Safari iOS 4 do not fire the window.onpopstate event when the hash has changed unlike the other browsers
    • Safari 5 and Safari iOS 4 fail to return to the correct state once a hash is replaced by a replaceState call / bug report
    • Safari 5 and Safari iOS 4 sometimes fail to apply the state change under busy conditions / bug report
    • Google Chrome 8,9,10 and Firefox 4 prior to the RC will always fire window.onpopstate once the page has loaded / change recommendation
    • Safari iOS 4.0, 4.1, 4.2 have a working HTML5 History API - although the actual back buttons of the browsers do not work, therefore we treat them as HTML4 browsers
  • HTML4 Browsers
    • Old browsers like MSIE 6,7 and Firefox 2 do not have a window.onhashchange event
    • MSIE 6 and 7 sometimes do not apply a hash even it was told to (requiring a second call to the apply function)
    • Non-Opera HTML4 browsers sometimes do not apply the hash when the hash is not urlencoded
  • All Browsers
    • State data and titles do not persist once the site is left and then returned (includes page refreshes)
    • State titles are never applied to the document.title

[fewdesign]

Hi,

For last month I am using jquery mobile. I’ve gone through lots of issues and learned a lot.

Web is good but when it comes with browser, HTML and java-scripts it becomes more buggy!

Generally I use chrome for development, and jquery mobile works perfect as it based on web-kit.

I tested and published my code, for desktop testing I use Firefox and chrome (not testing on IE as its jquery mobile). But when I open it in Android device, I see only half of the page rendering. And this is because of I made mistake in mark up language.

I forgot to close div tag and closed with li tag. In Firefox and chrome its ignored, but in safari it rendered differently.

Conclusion: While testing you web app IE is your acid test, while targeting web-kit or jquery mobile, safari is your acid test.

[NoNoNo]

I strongly second the use of the HTML5 History API through History.js.

[NoNoNo]

From what I read in the jQuery Mobile Blog (pushState landed: Now, clean URLs with Ajax-based navigation) this issue might get closed?!