Summary
The Cocoa implementation of org.eclipse.swt.browser.Browser is built on Apple's original, legacy WebKit API (WebView, WebFrame, WebDataSource, WebPreferences, WebScriptObject, DOMDocument, ...) — the API that shipped with Safari/WebKit in the mid-2000s.
The legacy WebView engine no longer receives the security fixes, web-standards support, or process-isolation/sandboxing that WKWebView gets, so the risk profile and rendering/JS compatibility of SWT's macOS Browser will keep drifting further from what modern web content expects. It also blocks access to WebKit features that only exist on WKWebView (e.g. the inspectable property requested in #757).
Without any concrete plans to migrate to the new API, this issue is supposed to make aware of the situation and collect information and insights related to it.
API evolution on macOS
- Apple introduced
WKWebView (WebKit.framework's modern, out-of-process API) in OS X 10.10 Yosemite (2014), as part of the "WebKit2" multi-process architecture.
- The legacy
WebView-based API was formally deprecated by Apple in macOS 10.14 Mojave (2018) (API_DEPRECATED in the headers, pointing to WKWebView).
- It has not been removed in the ~7 years since — Apple tends to keep deprecated AppKit/WebKit APIs functional for a long time — but there is no guarantee of continued availability, and no equivalent to the legacy
WebView API is being maintained going forward.
What adopting WKWebView would involve
- New native bindings. No
WK* JNI bindings exist in Eclipse SWT PI/cocoa/.../internal/cocoa/ today; the ~12 legacy binding classes (WebView, WebFrame, WebPreferences, WebScriptObject, ...) would need WK* counterparts (WKWebView, WKWebViewConfiguration, WKUserContentController, WKPreferences, WKNavigation, WKNavigationAction, WKScriptMessage, WKFrameInfo, ...) generated via SWT's JNIGenerator tooling and built into the native library.
- A different programming model. Legacy WebKit is synchronous/in-process;
WKWebView is async-only (completion handlers) and runs content out-of-process. Every blocking call path in the current implementation (script evaluation, navigation decisions, auth challenges, JS dialogs) needs restructuring around callbacks.
- A new JS↔Java bridge.
BrowserFunction currently relies on WebScriptObject; under WKWebView this becomes WKUserContentController/WKScriptMessageHandler-based message passing.
- Full feature-parity work: navigation, auth dialogs, context menus, downloads, popup/new-window handling, cookies, printing, and the rest of the
WebBrowser abstract API surface.
- A decision on minimum macOS deployment target, since parts of the
WKWebView API surface (e.g. inspectable) are only available from specific, comparatively recent macOS versions.
Relation to the Windows and Linux backends
SWT has been through this kind of migration twice before, replacing an aging embedded-engine backend with a modern, async, out-of-process one:
- Linux: WebKit1 → WebKit2GTK (visible today as the
Webkit2AsyncToSync synchronous-wrapper machinery in the GTK WebKit.java).
- Windows: Internet Explorer (Trident) → Edge/WebView2 (
Eclipse SWT Browser/win32/.../browser/Edge.java), which was introduced starting December 2020 and is still receiving fixes today, nearly five years later.
Both are useful reference points for how much calendar time and iteration this type of browser migration has historically taken in this project (which is rather about years than weeks).
Note on FFM vs. JNI
If this migration were started now, using the Java Foreign Function & Memory API (java.lang.foreign, JEP 454) instead of JNI could remove some friction: it avoids the native-compile step for adding new bindings, and its upcall stubs map naturally onto the delegate classes SWT's Cocoa layer already builds dynamically at runtime (objc_allocateClassPair/class_addMethod). It would not reduce the size of the actual migration (protocol coverage, async restructuring, JS-bridge redesign).
Summary
The Cocoa implementation of
org.eclipse.swt.browser.Browseris built on Apple's original, legacy WebKit API (WebView,WebFrame,WebDataSource,WebPreferences,WebScriptObject,DOMDocument, ...) — the API that shipped with Safari/WebKit in the mid-2000s.The legacy
WebViewengine no longer receives the security fixes, web-standards support, or process-isolation/sandboxing thatWKWebViewgets, so the risk profile and rendering/JS compatibility of SWT's macOSBrowserwill keep drifting further from what modern web content expects. It also blocks access to WebKit features that only exist onWKWebView(e.g. theinspectableproperty requested in #757).Without any concrete plans to migrate to the new API, this issue is supposed to make aware of the situation and collect information and insights related to it.
API evolution on macOS
WKWebView(WebKit.framework's modern, out-of-process API) in OS X 10.10 Yosemite (2014), as part of the "WebKit2" multi-process architecture.WebView-based API was formally deprecated by Apple in macOS 10.14 Mojave (2018) (API_DEPRECATEDin the headers, pointing toWKWebView).WebViewAPI is being maintained going forward.What adopting
WKWebViewwould involveWK*JNI bindings exist inEclipse SWT PI/cocoa/.../internal/cocoa/today; the ~12 legacy binding classes (WebView,WebFrame,WebPreferences,WebScriptObject, ...) would needWK*counterparts (WKWebView,WKWebViewConfiguration,WKUserContentController,WKPreferences,WKNavigation,WKNavigationAction,WKScriptMessage,WKFrameInfo, ...) generated via SWT's JNIGenerator tooling and built into the native library.WKWebViewis async-only (completion handlers) and runs content out-of-process. Every blocking call path in the current implementation (script evaluation, navigation decisions, auth challenges, JS dialogs) needs restructuring around callbacks.BrowserFunctioncurrently relies onWebScriptObject; underWKWebViewthis becomesWKUserContentController/WKScriptMessageHandler-based message passing.WebBrowserabstract API surface.WKWebViewAPI surface (e.g.inspectable) are only available from specific, comparatively recent macOS versions.Relation to the Windows and Linux backends
SWT has been through this kind of migration twice before, replacing an aging embedded-engine backend with a modern, async, out-of-process one:
Webkit2AsyncToSyncsynchronous-wrapper machinery in the GTKWebKit.java).Eclipse SWT Browser/win32/.../browser/Edge.java), which was introduced starting December 2020 and is still receiving fixes today, nearly five years later.Both are useful reference points for how much calendar time and iteration this type of browser migration has historically taken in this project (which is rather about years than weeks).
Note on FFM vs. JNI
If this migration were started now, using the Java Foreign Function & Memory API (
java.lang.foreign, JEP 454) instead of JNI could remove some friction: it avoids the native-compile step for adding new bindings, and its upcall stubs map naturally onto the delegate classes SWT's Cocoa layer already builds dynamically at runtime (objc_allocateClassPair/class_addMethod). It would not reduce the size of the actual migration (protocol coverage, async restructuring, JS-bridge redesign).