Wine (macOS/Linux): runtime appends removed --use-gl=swiftshader, so GL init aborts and the WebView paints only its first frame

Title

Wine/macOS+Linux: WebView2 appends --use-gl=swiftshader, a value Chromium no longer accepts, so GL init aborts and the WebView paints its first frame and never updates

Description

Under Wine, the WebView2 runtime appends --in-process-gpu --use-gl=swiftshader to the browser command line. swiftshader is no longer a valid --use-gl value (the implicit SwiftShader fallback was removed in Chrome 120+), so Chromium aborts GL initialisation before ANGLE is ever consulted. Every renderer context request then fails, the compositor produces zero frames, and the WebView shows its first frame forever.

This is not reproducible on Windows: Windows has a real WARP implementation, while the Wine D3D11 backends do not.

Environment

• CrossOver 26.3 (Wine 11.0 fork), macOS 26.7, Apple Silicon M1 Pro, Retina 2x
• WebView2 Evergreen runtime 153.0.4234.46 (installed via official standalone installer; install itself is fine — child processes spawn, navigation completes, CDP responds)
• Also reproduced with fixed-version runtime 149.0.4022.98 (see "Version behaviour" below)
• Host app: an open-source WinForms app (IAGD), but the failure is independent of it — see "Why it is not the host app"

Symptom

• First composited frame appears and is never updated. DOM, CSS, layout and hit-testing are all live and reachable over CDP.
• Measured with the window focused and raised:
  • document.visibilityState === "visible", document.hidden === false, wasDiscarded === false
  • requestAnimationFrame fires 0 times in 6 seconds
  • performance.getEntriesByType("paint") is empty
• Page.captureScreenshot hangs waiting for a frame that never arrives.
• Reproduces at both 1x and 2x DPI, so it is not a scaling issue.

Relevant log output

From --enable-logging --v=1 (<user-data-dir>/chrome_debug.log):

ERROR:ui\gl\init\gl_factory.cc:110] Requested GL implementation (gl=none,angle=none)
      not found in allowed implementations: [(gl=egl-angle,angle=default)].
VERBOSE1:gpu\ipc\service\gpu_init.cc:1127] gl::init::InitializeGLNoExtensionsOneOff failed
ERROR:ui\gl\init\gl_factory_win.cc:63] NOTREACHED hit.
ERROR:gpu\ipc\service\gpu_channel_manager.cc:927] ContextResult::kFatalFailure:
      Failed to create shared context for virtualization.
ERROR:gpu\ipc\service\shared_image_stub.cc:593] SharedImageStub: unable to create context
ERROR:gpu\ipc\service\gpu_channel.cc:826] GpuChannel: Failed to create SharedImageStub

The last three repeat in a hot loop — ~55,000 occurrences in a single short session.

The live argv of the browser process (read from the running process) shows the runtime's own flags at the end, after both the host app's AdditionalBrowserArguments and the HKLM\SOFTWARE\Policies\Microsoft\Edge\WebView2\AdditionalBrowserArguments policy:

--no-sandbox --disable-gpu-compositing --single-process
  ... <policy args> ... --use-gl=angle --use-angle=vulkan
--in-process-gpu --use-gl=swiftshader

Why it is not the host app

• The app can only prepend arguments. base::CommandLine takes the last occurrence of a duplicated switch, so the runtime's trailing --use-gl=swiftshader always wins. Verified: appending --use-gl=angle --use-angle=vulkan via the enterprise policy leaves the log at (gl=none,angle=none).
• The shipped WebView2Loader.dll, Microsoft.Web.WebView2.Core.dll and Microsoft.Web.WebView2.WinForms.dll contain none of these strings (searched in both ASCII and UTF-16). The swiftshader literal is present in msedgewebview2.exe itself.

Version behaviour (this narrows the bug considerably)

• 153.0.4234.46: --use-gl=swiftshader is unrecognised → GL init aborts at gl_factory.cc:110, ANGLE is never reached (zero eglInitialize lines in the log).
• 149.0.4022.98: the value is accepted — gl_factory.cc:110 never fires — and execution reaches ANGLE, which then fails one step later:
  eglInitialize D3D11Warp failed with error EGL_NOT_INITIALIZED / EGL Driver message (Critical) eglInitialize: No available renderers → GLDisplayEGL::Initialize failed. Still zero frames.

So there are two independent walls, and every configuration hits one or the other:

--disable-gpu	runtime	outcome
present	153	--use-gl=swiftshader unrecognised → GL init aborted
present	149	reaches ANGLE, pinned to D3D11Warp → no renderer in Wine
absent	153 / 149	--use-gl=swiftshader unrecognised → GL init aborted

Flags tried, all ineffective

--enable-unsafe-swiftshader, --use-angle=vulkan, --use-angle=swiftshader, --use-gl=angle, removing --disable-gpu, removing --disable-gpu-compositing, --disable-software-rasterizer (this one prevents the browser process from starting at all), --disable-direct-composition, --disable-gpu-vsync, --disable-frame-rate-limit, --force-device-scale-factor, --disable-features=CalculateNativeWinOcclusion, --enable-features=edge-webview-no-dpi-workaround.

Note --enable-unsafe-swiftshader only gates --use-angle=swiftshader; it does not make the legacy --use-gl=swiftshader value valid. And once --use-gl is unrecognised, Chromium appears to discard --use-angle as well, which is why the log reports (gl=none, angle=none) even when --use-angle=vulkan is present and not duplicated.

Wine-side check

Forcing d3d11 to Wine's own wined3d for msedgewebview2.exe only (via HKCU\Software\Wine\AppDefaults\msedgewebview2.exe\DllOverrides, *d3d11=builtin) does not help: the same D3D11Warp / No available renderers failure occurs. So neither CrossOver's DXMT nor wined3d implements D3D_DRIVER_TYPE_WARP, and d3d10warp.dll is absent from both the prefix and Wine's sysroot. This is also why the bug is macOS and Linux only, and never Windows.

Suggested fix

vk_swiftshader.dll (plus vk_swiftshader_icd.json and vulkan-1.dll) already ships in the runtime package. Under Wine, the runtime should therefore append the currently-valid software path —

--use-gl=angle --use-angle=vulkan

— instead of the removed --use-gl=swiftshader value, so ANGLE lands on CPU Vulkan/SwiftShader rather than on D3D11Warp, which no Wine D3D11 backend provides.

Longer term, the NOTREACHED + kFatalFailure hot loop (~55,000 iterations per session) is also burning CPU in a state that will never recover, and is worth backing off or failing visibly.

Repro steps

1. Install the Evergreen WebView2 runtime into a CrossOver (or any Wine) prefix with the official standalone installer.
2. Run any WinForms/WPF WebView2 app that renders a live-updating page, with --remote-debugging-port=9222 injected via the AdditionalBrowserArguments policy.
3. Confirm the first frame appears, then evaluate over CDP:

   new Promise(res => { let n = 0; const t0 = performance.now();
     (function tick(){ n++; if (n < 40) requestAnimationFrame(tick);
       else res(JSON.stringify({frames:n, ms:performance.now()-t0})); })();
     setTimeout(() => res(JSON.stringify({frames:n, ms:performance.now()-t0, hitTimeout:true})), 6000); })
   

   → frames: 0, and performance.getEntriesByType("paint") is empty, while document.visibilityState is "visible".
4. Add --enable-logging --v=1 and read <user-data-dir>/chrome_debug.log for the gl_factory.cc:110 line.

Happy to provide the probe scripts, full logs, and a minimal repro host app if that helps.

Start with the WebView2 browser process command line and /chrome_debug.log, then reproduce the issue under Wine using the provided CDP probe. Compare the runtime's trailing flags with the suggested Vulkan/SwiftShader path and verify that live frames resume without the GL initialization failure or hot loop.