WebGPU backend fails (device lost) on Safari 26 (macOS + iOS) when building to WASM using Emscripten #9103
Description
Version/Branch of Dear ImGui:
master
Back-ends:
imgui_impl_glfw.cpp + imgui_impl_wgpu.cpp
Compiler, OS:
macOS emscripten
Full config/build information:
Copy/paste from clipboard doesn't seem to work when running inside a browser so here's a screenshot running in Chrome:
Details:
I am not sure this is actually a bug in the ImGui WebGPU backend instead of a bug in Safari 26, but I wanted to report it here anyway in case someone else runs into this problem, or someone better at WebGPU debugging knows a way to further analyse. I also filed a bug against Safari directly with Apple.
I built a simple WebGPU application that can use both a native backend (using wgpu-native) or can be compiled to WASM using Emscripten, and uses Dear ImGui to render its UI. The application works perfectly in all of the following situations:
- Compiled to WASM/Emscripten in Chrome & Firefox, on both macOS and Linux
- Compiled to native using wgpu-native backend on both macOS and Linux
However, the ImGUI-related parts of the application do not work in the following situations:
- Compiled to WASM/Emscripten in Safari 26.1 (with WebGPU flags enabled obviously) on macOS, or on iOS 26 Safari (WebGPU enabled by default)
In the above scenario, WebGPU is working correctly in Safari for a simple triangle render pass, but as soon as I dispatch the ImGui render pass, the application aborts with a device lost (destroyed) error.
My application is directly derived from the example_glfw_wgpu.cpp example, and the problem can easily be reproduced with that example by compiling to WASM using Emscripten, serving the shell HTML using python http.server and loading it in Safari. The ImGui example also works fine for all other combinations of browsers and platforms, it is just Safari that fails.
I have not been able to get any kind of error information or validation messages from either Safari, Chrome, Firefox or wgpu-native, which suggest again the problem is not in the application itself, but the example hits some unsupported or bugged case in the Safari WebGPU backend.
I tried to pinpoint the exact point that triggers the error and the closest I got was the following statement on line 358 of backends/imgui_impl_wgpu.cpp:
wgpuRenderPassEncoderSetPipeline(ctx, bd->pipelineState);
My guess/assumption is that the pipeline for the ImGui render pass is configured to use some feature or bind group layout that triggers some internal assertion in the Safari WebGPU backend or causes some kind of invalid buffer access. So again, I do not think this is necessarily a problem in Dear ImGui itself, and this report is mostly intended to be helpful in case someone else runs into the same issue. I would not also not be surprised if some simple change in the ImGui WebGPU backend could potentially side-step this issue so ImGui could work on Safari even despite a potentially broken WebGPU backend, which would of course be preferred to having to wait until Apple fixes this (if ever).
Screenshots/Video:
No response
Minimal, Complete and Verifiable Example code:
- The example_glfw_wgpu.cpp included with Dear ImGui reproduces this problem when compiled to WASM using Emscripten when run with Safari 26.1 on macOS
- Live demo application I've been using can be accessed here [1]
[1] https://www.wouterbijlsma.nl/~wouter/tmp/wgpu-playground/wgpu-playground.html