This will be fixed in the next build though the source of the problem is deeply troubling and unsolved.
Basically, that screen creates three UIWebViews, one for the question and one for each answer. Each web view then loads the post HTML using the post's link as a base URL. This last part is important for site and protocol relative links. The setup looks kind of like this:
WebView | baseURL
--------------------------------
Q | /questions/1/title
A1 | /questions/1/title/2#2
A2 | /questions/1/title/3#3
Here's where things get weird. Each web view calls its delegate's - webView:shouldStartLoadWithRequest:navigationType:
method to see check whether or not it should render the content. That method looks like this:
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType
{
NSURL *mainURL = request.mainDocumentURL;
// Part 1
if ([self.baseURL isEqual:mainURL] || [mainURL.absoluteString isEqualToString:@"about:blank"]) {
return YES; // initial load
}
// Part 2
if ([mainURL.scheme isEqualToString:@"code"]) {
[self.postInteractionDelegate postView:self didRequestDisplayOfPrePrettifiedCode:[webView stringByEvaluatingJavaScriptFromString:@"codeHTML"] site:self.site viewportWidth:[[webView stringByEvaluatingJavaScriptFromString:@"codeWidth"] floatValue]];
} else {
[self.postInteractionDelegate postView:self didRequestNavigationToURL:mainURL];
}
return NO;
}
Part 1 handles the initial load case for the post. Part 2 handles tapping images, links, or code blocks. For some reason in this specific post WebView A2's delegate is receiving a navigation request intended for WebView A1. This means that the test in Part 1 fails and it chooses to push a new question view controller that scrolls to A1. It is also impossible to tell what's happening since webView
and self.webView
both point to WebView A2.
Since this doesn't happen on other questions (and our behavior has been this way for well over a year) I'm putting all the blame on the fact that the two answer have the same video embedded and a bad logic check in iOS's logic for looking up web views corresponding to WebKit objects.
The good news is that I can just use the same URL for all the web views and the logic for loading becomes identical for all three web views so no matter which incorrect delegate gets called at that point Part 1 will pass. I've seen no other ill effects so it looks like all other delegate calls are going to their rightful owners.