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