wiki:WKWebViewAnEmbeddersPerspective

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
Last modified 4 years ago Last modified on Nov 1, 2019 4:13:25 PM