I'm embedding this web site into my app like this:
NSString *url = [NSString stringWithFormat:@"https://mobile.twitter.com/search?q=%@", @"@test OR #test"];
url = [url stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
[self.twitterWebView loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:url]]];
self.twitterWebView.scalesPageToFit = YES;
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
webView:shouldStartLoadWithRequest:navigationType:), going forward or back is not possible anymore.
canGoBack will return
goBack won't do anything. This persists across restarts of the app, as long as the HTML5 cache for this specific site exists.
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.
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.
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.
This problem still exists in iOS 7.1 and and OS X 10.9.2.
This bug has been fixed in iOS 8 and Safari 7.1 (95188.8.131.52.1) for OS X!