= WKWebView: An Embedder’s Perspective
''by Ali Juma, Google''

- Chrome on iOS
    - Originally used UIWebView
    - Moved to WKWebView in 2016
    - Goal: Offer the same browser features as Chrome on other platforms
        - Sync
        - Translate
        - Autofill
        - Find-in-Page
- Challenge: API limitations
    - History is immutable
    - Must use inejected JS for features involving web content
    - Can’t message an individual iframe
    - Injected JS is visible to page script
    - Can’t customize network stack
- History: working around immutability
    - Problem: Users expect their open tabs and history to be preserved
    - Solution: Observe and maintain a parallel back/forward list
    - On app startup
        - Load html file that uses replaceState and pushState to populate history with file URLs
        - When visiting such a file URL, redirect an actual target
    - This is complex with lots of bugs
- What’s the right URL to display?
    - 99% of the time, it’s WKWebView.URL
    - Problem: WKWebView.URL updates eagerly on navigations
    - Attempted solution:
        - Hueristics involving WKWebView.URL, WKBackForwardList.currentItem
    - But URL spoofs are our #1 source of security bugs
- Implementing browser features in JavaScript
    - General approach:
        - Inject JS on page load
        - Register script message handlers to receive messages from JS
        - Inject JS in response to message or to user action
    - Problem: All this script is visible to (and modifiable by) page script
        - Haven’t seen problems, but seems like a bug waiting to happen
    - Problem: URL confusion
- iframes: working around no direct messaging
- Problem: implement features like autofill and find-in-page in iframe
    - Need to secure communication between the app and an iframe
- Solution: encryption + broadcast messaging
    - iframe: create a public/private key pair, send public key to app
    - app: send encrypted messages to the main frame
    - Main frame: broadcasts the messages to all frames
    - Target frame: decrypts the message
- Working with offscreen WKWebViews
    - Why use offscreen WKWebviews?
        - Preload likely next destination page
        - DOM distillation for reader mode
    - Problems:
        - Process suspension
        - Dealing with permission prompts
- Proactively avoid breakage
    - Bot that runs all tests using trunk WebKit rather than shipping WebKit
        - Currently an FYI bot
    - Bot that runs all WPT
        - WiP
        - Test runner works locally
    - Fuzzing
        - Early WiP
        - Goal: Find bugs by fuzzing MiniBrowser on macOS