| 1 | = WKWebView: An Embedder’s Perspective |
| 2 | ''by Ali Juma, Google'' |
| 3 | |
| 4 | - Chrome on iOS |
| 5 | - Originally used UIWebView |
| 6 | - Moved to WKWebView in 2016 |
| 7 | - Goal: Offer the same browser features as Chrome on other platforms |
| 8 | - Sync |
| 9 | - Translate |
| 10 | - Autofill |
| 11 | - Find-in-Page |
| 12 | - Challenge: API limitations |
| 13 | - History is immutable |
| 14 | - Must use inejected JS for features involving web content |
| 15 | - Can’t message an individual iframe |
| 16 | - Injected JS is visible to page script |
| 17 | - Can’t customize network stack |
| 18 | - History: working around immutability |
| 19 | - Problem: Users expect their open tabs and history to be preserved |
| 20 | - Solution: Observe and maintain a parallel back/forward list |
| 21 | - On app startup |
| 22 | - Load html file that uses replaceState and pushState to populate history with file URLs |
| 23 | - When visiting such a file URL, redirect an actual target |
| 24 | - This is complex with lots of bugs |
| 25 | - What’s the right URL to display? |
| 26 | - 99% of the time, it’s WKWebView.URL |
| 27 | - Problem: WKWebView.URL updates eagerly on navigations |
| 28 | - Attempted solution: |
| 29 | - Hueristics involving WKWebView.URL, WKBackForwardList.currentItem |
| 30 | - But URL spoofs are our #1 source of security bugs |
| 31 | - Implementing browser features in JavaScript |
| 32 | - General approach: |
| 33 | - Inject JS on page load |
| 34 | - Register script message handlers to receive messages from JS |
| 35 | - Inject JS in response to message or to user action |
| 36 | - Problem: All this script is visible to (and modifiable by) page script |
| 37 | - Haven’t seen problems, but seems like a bug waiting to happen |
| 38 | - Problem: URL confusion |
| 39 | - iframes: working around no direct messaging |
| 40 | - Problem: implement features like autofill and find-in-page in iframe |
| 41 | - Need to secure communication between the app and an iframe |
| 42 | - Solution: encryption + broadcast messaging |
| 43 | - iframe: create a public/private key pair, send public key to app |
| 44 | - app: send encrypted messages to the main frame |
| 45 | - Main frame: broadcasts the messages to all frames |
| 46 | - Target frame: decrypts the message |
| 47 | - Working with offscreen WKWebViews |
| 48 | - Why use offscreen WKWebviews? |
| 49 | - Preload likely next destination page |
| 50 | - DOM distillation for reader mode |
| 51 | - Problems: |
| 52 | - Process suspension |
| 53 | - Dealing with permission prompts |
| 54 | - Proactively avoid breakage |
| 55 | - Bot that runs all tests using trunk WebKit rather than shipping WebKit |
| 56 | - Currently an FYI bot |
| 57 | - Bot that runs all WPT |
| 58 | - WiP |
| 59 | - Test runner works locally |
| 60 | - Fuzzing |
| 61 | - Early WiP |
| 62 | - Goal: Find bugs by fuzzing MiniBrowser on macOS |