Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

macOS Browser uses a long-deprecated WebKit API

Đang mở
  • Có gì không ổn?
#3,486 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
15/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Ít trao đổi
Công nghệ
java, macos
Lĩnh vực
desktop, web-dev

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
Java
Star
202
Fork
206
Merge trung bình
14 giờ 7 phút
Pull request đã merge (30 ngày)
103

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của eclipse-platform/eclipse.platform.swt

Tất cả issue của eclipse-platform/eclipse.platform.swt

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.