Electrobun: support non-CEF (native-renderer) apps to fill the Linux/Windows gaps

[goosewobbler]

Summary

The initial 0.1.0 release of @wdio/electrobun-service supports CEF-rendered apps only, and (per the upstream CEF profile catch-22) ships macOS-only. But Electrobun's defaultRenderer is "native" — most shipped apps use the system webview, not CEF. This issue tracks the follow-up to support non-CEF (native-renderer) Electrobun apps where the platform's webview is drivable, to fill the Linux/Windows gaps the CEF path can't.

The service is intentionally pre-1.0 (0.1.0) because of these gaps — 1.0 is the full release once they're filled. This work is therefore part of the road to 1.0 (a minor-bump item on the 0.x line, e.g. 0.2.0), landing after the 0.1.0 ship (PR5). It does not gate the 0.1.0 release. This is the consumer-side track; the upstream CEF fixes are tracked separately (see "Out of scope").

Background

0.1.0 forces the CEF renderer for a uniform Chromium/CDP target model. CEF's chrome-runtime can't create the persist:default profile its BrowserWindow forces and falls back to a global browser context — macOS recovers (serves /json), Linux/Windows don't → 0.1.0 is macOS-only CEF (see #316). Since most apps ship the native renderer, a CEF-only service tests something users largely don't ship; supporting native renderers both broadens coverage and fills the OS gaps. Filling them (alongside the upstream CEF fixes) is part of what graduates the service from 0.x to 1.0.

Per-renderer feasibility (verified against the electrobun source)

OS	Native renderer	Remote surface	Transport	Feasibility
Windows	WebView2 (Chromium)	CDP	CDP-attach (existing bridge)	✅ likely service-side only — set WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--remote-debugging-port=N on the spawned app; no upstream dependency. Start here.
Linux	WebKitGTK	W3C WebDriver (WebKitWebDriver)	external-driver archetype (as Tauri/Dioxus Linux)	⚠️ needs upstream (webkit_web_context_set_automation_allowed + automation-started; Electrobun wires only the local inspector) plus a second transport
macOS	WKWebView	none (local Web Inspector GUI only)	—	❌ no remote automation surface → stays CEF

Source refs: package/src/native/win/nativeWrapper.cpp (WebView2 put_AdditionalBrowserArguments); linux/nativeWrapper.cpp (only webkit_web_view_get_inspector, no automation-allow); macos/nativeWrapper.mm (developerExtrasEnabled + private _inspector, no remote surface); bun/core/BuildConfig.ts (defaultRenderer: "native").

Key principle: additive, not a substitute

• It does not reduce the CEF-app upstream asks — a CEF-app user still needs every one of them.
• It brings its own, separate upstream gap (Linux WebKitGTK automation-allow).
• → two independent upstream dependency sets. macOS must remain CEF regardless.

Proposed sequencing

1. Windows / WebView2 + CDP — highest leverage, no upstream dependency. Validate WebView2 /json discovery; reuse the existing CDP bridge + multi-target model.
2. Linux / WebKitGTK + W3C WebDriver — gated on the upstream automation-allow change; adds the external-driver archetype to the service.
3. macOS — no action; stays CEF.

Each landed renderer should re-add the matching CI leg, lift the corresponding docs limitation, and bump the minor version — converging on 1.0.

Out of scope

• Upstream electrobun CEF fixes (profile fallback, Linux remote_debugging_port, root_cache_path override, single-instance/open-url) — tracked repo-side in Electrobun: track upstream CEF fixes (Linux/Windows, multiremote, multi-window, deeplink) #320 (which maps each upstream fix to what it unblocks); the upstream umbrella issue against blackboardsh/electrobun will be linked from there.
• macOS native (WKWebView) automation — WKWebView exposes no remote automation surface, but an embedded WebDriver server we ship ourselves is feasible without upstream changes: a Bun-side package the app registers (the tauri-plugin-wdio-webdriver / wdio-dioxus-embedded-driver model), serving W3C WebDriver from the Bun process and driving webviews via executeJavascript plus the existing webview→Bun RPC channel for result return. A separate archetype with its own caveats (JS-synthesised input, no screenshot API exposed) — file its own issue if/when prioritised.