Why is UIWebView canGoBack=NO in iOS7?

aslisabanci picture aslisabanci · Sep 22, 2013 · Viewed 10.1k times · Source

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;

And I have 2 buttons for going back and forward in this web site. I'm calling

[self.twitterWebView goBack]; and
[self.twitterWebView goForward]; accordingly.

This works fine on iOS 6 but on iOS 7, my web view's canGoBack and canGoForward properties are NO and thus my back and forward buttons do not work.

As a side note, when the app is installed the first time, and the page is loaded the first time, my buttons work. But when I run my app again, and when I tap on a link on the web site, my web view's canGoBack property begins returning always NO.

How can I solve this?

EDIT: I uploaded a mini test app that demonstrates my problem. You can download it from here. Please run the app on an iOS 7 simulator, see that the back button is working on the first installation of the app. Then quit, run the app again and you'll see that it'll stop working.

By the way the problem seems to be about the twitter mobile site. You can try another web site address and see that.

Answer

Andreas Ley picture Andreas Ley · Oct 29, 2013

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: