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 isolation — BrowserWindow 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)
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.
Summary
@wdio/electrobun-servicedrives the CEF renderer on macOS; CEF stays macOS-only (Linux/Windows CEF can't create thepersist:defaultprofile — see #316 and the README Known limitations). Windows ships via the native WebView2 renderer instead (the non-CEF track, #317 — done and gated in0.1.0), so the service is no longer macOS-only, but the CEF path is. This issue tracks the CEF-side road to1.0from 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.
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:defaultprofile 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 CEFroot_cache_pathlock doesn't release at teardown on Windows (EPERM), so subsequent app instances failFailed 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)
BrowserWindowforcespersist: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).GetGlobalContext()band-aid — why macOS recovers)switchWindow/listWindows→ re-fold the CEFwindowsuite); de-flakes the macOSstandardgate (dropspecFileRetries: 3); reliable single-window/json; also the blocker for CEF-on-Linux and CEF-on-Windows/jsonremote_debugging_portdisabled — commented out in the Linux wrapper.root_cache_path— derived solely from identifier+channel, so ≥2 processes share one cache root and CEF folds them.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 CEFLift— done on WebView2 (Windows); macOS CEF stays single-instance pending fix 3maxInstances: 1and validate multiremotewindowanddeeplinksuites into the CI matrix (currently local-only viaTEST_TYPE=window|deeplink) — needs fixes 1/4SevereServiceErrorguard once Linux is drivable (CEF via 1+2, or WebKitGTK via #467)specFileRetries: 3in the macOS CEF conf once the race is gone1.0.0at full parityWhy 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.