This seems to be related to HTML5's "Application Cache" functionality. On first launch, the site isn't cached and the UIWebView
correctly detects if it can go forward or back. As soon as the cache is populated, new UIWebView
instances decide that, even if the URL changes (which can be observed in UIWebViewDelegate
's webView:shouldStartLoadWithRequest:navigationType:
), going forward or back is not possible anymore. canGoForward
and canGoBack
will return NO
and goForward
and goBack
won't do anything. This persists across restarts of the app, as long as the HTML5 cache for this specific site exists.
Maybe this problem is limited to web apps that modify the URL's Fragment identifier after the hashmark via JavaScript.
And yes, the UIWebView
's behavior in this situation DID change between iOS 6 and iOS 7.
I haven't found a solution yet, and we'll probably have to wait for Apple to fix this in iOS 7.1 or so.
Edit
Other people have this problem, too:
If you are using Application Cache and also managing states through hash or other technique, the history object will not keep your navigation history, therefore history.back() will never work and history.length stays in 1 forever.
(from http://www.mobilexweb.com/blog/safari-ios7-html5-problems-apis-review)
Edit 2
This problem exists in Safari 7.0 (9537.71, default in OS X 10.9 Mavericks), too. However, the most recent WebKit nightly build (r158339) seems to work correctly. It's most likely only a matter of time until the fix makes it to an iOS and OS X release.
Edit 3
This problem still exists in iOS 7.1 and and OS X 10.9.2.
Edit 4
This bug has been fixed in iOS 8 and Safari 7.1 (9537.85.10.17.1) for OS X!
Related: