| | 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 |
