@Mhurd this should be ready to go for you now - let me know if you think there are any other questions we need to answer.

Quick proof-of-concept:
https://github.com/wikimedia/wikipedia-ios/pull/778

@Fjalapeno @JMinor @JoeWalsh @RHo

Results from spike investigation:

• Quick proof of concept implementation of basic back-end functionality including an animated gif: https://github.com/wikimedia/wikipedia-ios/pull/778

Finding

Q: Can we search for a text string within the web view content itself?
A: Yes - and based on my quick proof-of-concept is appears WKWebView makes this fairly performant, even when searching large articles like "enwiki > Barack Obama" for the term "Obama", which had almost 300 matches.

Q: Or is it better search the html on disk?
A: Ideally we'd want to search visible DOM text nodes because they are the ultimate source of truth for whether matches are actually visible. Searching the raw html doesn't have this context without basically reconstructing some part of the DOM to try to tease out context around string matches - i.e. is it in a text element, is it visible etc. Given that WKWebView's JS performance seems good, it makes sense to ask it for visible DOM text nodes rather than trying to reconstruct what it already knows. Dealing with matches is also easier when done in JS on a matching DOM text node basis - it simplifies highlighting because you can add a highlighting span right away.

Q: It we find it using the html on disk, can we easily locate the string in the web view's html?
A: This would be more complicated because of the of the extra parsing mentioned in the note above which would be necessary to get visibility and node type context. It would be possible, it would just be more complicated.

Q: Is Adam's code for extracting the share a fact text useful here?
A: Not really. Pretty divergent use case.

Q: Are we able to search image captions?
A: Yes - the proof of concept should do this for free

Q: Can we exclude non-visible text (like href urls) form the search?
A: Yes - the proof of concept should do this for free

Highlighting

Q: Can we get the frame of any text we find in the we view?
A: Yes - the proof of concept is doing this

Q: What about text that spans multiple lines?
A: Yes - the proof of concept is doing this

Q: Can we use CSS to highlight the text?
A: Yes - the proof of concept is doing this

Q: Can we use native views to highlight the text? Is this harder than CSS?
A: We could, but it would be more complicated and brittle than the proof-of-concept approach. The proof-of-concept approach can even be easily modified to do things such as use CSS animation to make a search result "pulse" when the user taps a "next" button and we scroll down to subsequent matches.

Q: Can we animate the highlight? (Think fade in/out and scale)
A: Yes - we can actually easily accomplish this with CSS animation of the span we use to highlight matches

Navigating

Q: Can we scroll (with animation) to the position of a specific string of text?
A: Yes - the proof-of-concept is doing this already

Back-end (proof-of-concept does all of these already!)

• ability to search for matches
• ability to highlight matches
• ability to know number of matches
• ability to scroll article between matches
• ability to clear for matches

Proposed basic interface

• add some sort of find-in-page icon
• tapping it shows a native find-in-page search field
• searching for a term highlights all matches
• native count of number of matches, or "No matches found" message found appears
• native next and back button appear
• these buttons simply scroll the article between matches
• does small css animation of the match when scrolling to it

Rough estimate of time to implement Proposed basic interface

• My best guess is 1 to 3 days. The proof-of-concept is already pretty solid and has most of the sought functionality.