The WebGPU specification defines `attribute EventHandler onuncapturederror` on GPUDevice. Safari 26.6 does not implement it. `addEventListener('uncapturederror', ..)` works, so the event itself is dispatched; only the event-handler IDL attribute is missing. STEPS TO REPRODUCE const device = await (await navigator.gpu.requestAdapter()).requestDevice(); console.log('onuncapturederror' in device); // false console.log(typeof device.onuncapturederror); // undefined device.onuncapturederror = () => console.log('setter fired'); device.addEventListener('uncapturederror', () => console.log('listener fired')); // now trigger any device error, for example an invalid createComputePipeline EXPECTED Both fire. Chrome 152 reports `'onuncapturederror' in device === true` and calls both. ACTUAL Only the addEventListener callback fires. Assigning to device.onuncapturederror creates an ordinary expando property that nothing ever calls, so it fails silently: the page has no indication that its error handler is not installed. WHY IT MATTERS MORE THAN IT LOOKS wgpu, the Rust WebGPU implementation used by most Rust code targeting the web, installs its uncaptured-error handler by assigning to this attribute (wgpu-30.0.1/src/backend/webgpu.rs:2641, `set_onuncapturederror`). On Safari that means `Device::on_uncaptured_error` is dead code for every error, so no Rust WebGPU application sees any uncaptured device error at all unless it also pushes explicit error scopes. I hit this alongside bug 323543, a WGSL to MSL translation bug, where a shader failed to compile, every pipeline was invalid, every submit was a no-op, and the application read back unwritten buffers and produced a wrong answer with no error raised anywhere. The translation bug is the defect; this one is why it took a day to find. ENVIRONMENT Safari 26.6 (WebKit 605.1.15), macOS on Apple M2 Max. Control: Chrome 152.0.7977.66, same machine, both handlers fire.