Skip to content

Electrobun: track upstream CEF fixes (Linux/Windows, multiremote, multi-window, deeplink) #320

@goosewobbler

Description

@goosewobbler

Summary

@wdio/electrobun-service drives the CEF renderer on macOS; CEF stays macOS-only (Linux/Windows CEF can't create the persist:default profile — see #316 and the README Known limitations). Windows ships via the native WebView2 renderer instead (the non-CEF track, #317 — done and gated in 0.1.0), so the service is no longer macOS-only, but the CEF path is. This issue tracks the CEF-side road to 1.0 from our repo: which upstream fix unblocks which CEF surface, why each is required, and the consumer-side re-fold work as each lands.

It is the sibling of #317 (the non-CEF / native-renderer track). The two tracks have independent upstream dependency sets and are both additive — a CEF-app user still needs every fix below even after #317 lands.

Upstream umbrella issue: filed — blackboardsh/electrobun#466 (one umbrella linking electrobun's existing issues, not N duplicates). The CEF-on-Windows finding below is recorded there too.

CEF-on-Windows is a dead end (verified via a spike, 2026-06)

A CEF build on Windows is not a viable alternative to the WebView2 path: it hits the same persist:default profile gap as Linux (Cannot create profile at …\CEF\partitions\default). The first instance limps up and does serve /json (a full functional suite passed against it), but the shared CEF root_cache_path lock doesn't release at teardown on Windows (EPERM), so subsequent app instances fail Failed to initialize CEF. Net: CEF-on-Windows is drivable for a single instance but not re-startable / not multi-instance — it would need fix #1 plus the Windows lock-release angle of fix #3. Windows is already covered by WebView2 (#317), so these CEF fixes are needed only to drive CEF apps on Windows, not for Windows coverage.

Upstream fixes → what each unblocks (CEF)

# Upstream fix Existing upstream refs Unblocks
1 Profile isolationBrowserWindow forces persist:default, which the CEF chrome-runtime can't create as a non-global profile (falls back to the global context; macOS limps, Linux/Windows error). #380 (proper fix), #448 (identical Linux error), #278 (closed GetGlobalContext() band-aid — why macOS recovers) Reliable macOS CEF multi-window (switchWindow/listWindows → re-fold the CEF window suite); de-flakes the macOS standard gate (drop specFileRetries: 3); reliable single-window /json; also the blocker for CEF-on-Linux and CEF-on-Windows /json
2 Linux remote_debugging_port disabled — commented out in the Linux wrapper. #445, #448 Any CEF CDP on Linux at all (with fix 1) → CEF-Linux build + e2e
3 Per-instance root_cache_path — derived solely from identifier+channel, so ≥2 processes share one cache root and CEF folds them. #380 CEF multiremote / parallel workers on macOS — and the Windows lock-release wrinkle above. (multiremote already works on the WebView2 path, #317.)
4 Single-instance lock + open-url routing — handling exists on macOS, but nothing stops a second launch spawning a fresh process. #465 Reliable triggerDeeplink (macOS CEF; Windows also needs URL-scheme registration, folded into #465)

CEF-on-macOS multi-window/deeplink need fix 1/4; CEF-on-Linux needs 1+2; CEF-on-Windows needs 1 (+3). Windows coverage itself is via WebView2 (#317), not CEF.

Consumer-side re-fold checklist (as each fix lands)

  • Re-add the Windows fixture-build + e2e CI jobs — done via the WebView2 path (Electrobun: support non-CEF (native-renderer) apps to fill the Linux/Windows gaps #317), not CEF
  • Lift maxInstances: 1 and validate multiremote — done on WebView2 (Windows); macOS CEF stays single-instance pending fix 3
  • Re-add the Linux CEF fixture-build + e2e CI jobs (needs fixes 1+2)
  • Re-fold the macOS CEF window and deeplink suites into the CI matrix (currently local-only via TEST_TYPE=window|deeplink) — needs fixes 1/4
  • Relax the launcher's Linux native-mode SevereServiceError guard once Linux is drivable (CEF via 1+2, or WebKitGTK via #467)
  • Drop the fixtures' staggered-second-window workaround + the single-window caveat (CEF) once fix 1 lands
  • Drop specFileRetries: 3 in the macOS CEF conf once the race is gone
  • Lift the matching README/docs limitation rows; converge on 1.0.0 at full parity

Why a repo-side issue

The upstream umbrella (blackboardsh/electrobun#466) tracks the electrobun changes; this issue tracks both sets of changes from our side — the mapping from upstream fix → CEF service surface, and the re-fold work that is ours regardless of where the fixes land. #317 deliberately scopes these out; this is where they live.

Metadata

Metadata

Assignees

No one assigned

    Labels

    os:linuxLinux-specific issuesos:macosMacOS-specific issuesos:windowsWindows-specific issuesscope:electrobunElectrobun servicestatus:blockedWork cannot start until something is resolvedtype:taskTask(s) to complete

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions