Bug 221655
| Summary: | WKWebView needs a synchronous API for JavaScript/DOM access | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Jonathan Deutsch <jonathan> |
| Component: | WebKit API | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Blocker | CC: | achristensen, cdumez, ggaren, jonathan, sam, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 14 | ||
| Hardware: | Mac (Apple Silicon) | ||
| OS: | macOS 11 | ||
Jonathan Deutsch
Practically speaking, applications that are tightly integrated with a web view have to go through clunky control flow contortions to deal with the callback structure of WKWebView's -evaluateJavaScript:/-callAsyncJavaScript: methods to access the DOM.
The only reasonable solution for handling this is to shove more and more of the application logic into JavaScript, at which point there is less of a reason to develop a native Mac app anymore.
For the time being, I have developed my own synchronous solution that reproduces the WebView Legacy DOM API. This uses run loop shenanigans and has significant drawbacks.
At the very least, WKWebView could at least not use the main run loop for its communication channel and not have locks where the child process will not respond properly if it cannot talk to to the main app. This would at least allow for using a dispatch_semaphore_wait() that gets signaled in the callback.
WKWebView could easily provide a better API, and it could probably be more performant too. I am surprised WebView was deprecated without providing this.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/74423269>