Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

macOS Browser uses a long-deprecated WebKit API

Aperta
  • Qualcosa non va?
#3,486 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
15/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
java, macos
Ambito
desktop, web-dev

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

macOS

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

Lingua principale
Java
Stelle
202
Fork
206
Merge medio
16h 56m
PR unite (30g)
110

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di eclipse-platform/eclipse.platform.swt

Tutte le issue di eclipse-platform/eclipse.platform.swt

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.