In WMFAppViewController, it presents the VC in (WMFArticleViewController *)showArticleWithURL:(NSURL *)articleURL animated:(BOOL)animated completion:(nonnull dispatch_block_t)completion

Unfortunately, it's presenting it on DDParsecRemoteCollectionViewController - which isn't in our app, and from a quick search seems to be part of spotlight. This would make sense as to why it's immediately disappearing afterwards.

For the PR Figure out why currentNavigationController is returning this instead of our app's NavController, and fix it.

It seems like this is because we take our tabViewController's presentedViewController. Unfortunately, in this situation it's the spotlight VC, and it has no relationship to our app's VCs, so we can't start with it and work our way to the expected VC. I think the only way to do this is to work our way up from the tabVC. This gets a tiny bit tricky, as VCs and NavControllers may be pushed or presented on any variety of VCs, so we need to carefully traverse our way up the stack.

I'm going to keep thinking about if there is a way to get the presented VC that is actually part of our app, and maybe check in w/ other engineers next week.

PR up shortly. For posterity, the problem:
When a user was in our app, selected a word/phrase, then tapped "Look Up" (and entered the iOS overlay), then tapped the "Siri Knowledge" cell (if available), then tapped "Wikipedia": iOS's overlay would open the link in the app, but currentNavigationController would present the new article VC on the iOS Look Up VC, not the original article VC (as expected). Since the iOS Look Up VC would deinit nearly immediately, the new article would close after a split second.

While we DDParsecCollectionViewController is a private iOS class, we can use NSStringFromClass to see if a VC is about to be presented on this iOS screen, and if so move up the hierarchy.

PR: https://github.com/wikimedia/wikipedia-ios/pull/4226

monospaced text

Looks good to me on 6.9.1 (1930)