macOS Browser uses a long-deprecated WebKit API

This issue is an awareness and information-gathering discussion, not a defined migration task. For context, read the Cocoa browser implementation and native bindings under Eclipse SWT PI/cocoa/.../internal/cocoa/, plus the GTK WebKit.java and Windows Eclipse SWT Browser/win32/.../browser/Edge.java examples named in the issue. No specific change or completion criteria are defined; the migration would require a project-level decision and extensive feature-parity work.

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