electron / electron/electron

[Bug]: navigator.usb.requestDevice() crashes the browser process (SIGSEGV) on a named session partition

Open
#52,383 0 comments 0 reactions 1 assignee Claimed by @dsanders11 View on GitHub
43-x-y bug :beetle: component/deviceAccess has-repro-gist platform/macOS
Dominant language
C++
Stars
123k
Forks
17.5k
Avg merge
14h 22m
Merged PRs (30d)
873

Description

### Preflight Checklist

- [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [x] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

43.1.1

### What operating system(s) are you using?

macOS

### Operating System Version

macOS Tahoe 26.5.2 (25F84)

### What arch are you using?

arm64 (including Apple Silicon)

### Last Known Working Electron version

Unknown — every version I tested reproduces (41.10.0, 41.10.2, 43.1.1); not bisected further back.

### Does the issue also appear in Chromium / Google Chrome?

I don't know how to test

### Expected Behavior

Calling `navigator.usb.requestDevice({ filters: [] })` from a window whose `webPreferences.partition` is a **named session** should reject with `NotFoundError` — exactly as it does with the default session — when no device is selected / no `select-usb-device` handler is registered.

### Actual Behavior

The **browser process** crashes with `SIGSEGV` (`EXC_BAD_ACCESS` on `CrBrowserMain`).

The trigger is the named session partition: with the **default** session the identical call rejects cleanly with `NotFoundError: No device selected`. `navigator.bluetooth.requestDevice()` crashes the same way. Registering a `select-usb-device` handler that cancels the request (`event.preventDefault(); callback()`) does **not** prevent the crash — the fault happens in native code before the JS handler resolves.

```
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000100
Triggered by Thread: 0 CrBrowserMain

Thread 0 Crashed:: CrBrowserMain
0 Electron Framework v8::CppHeap::Create(...)
1 Electron Framework node::PrincipalRealm::...
```

(Symbol names are nearest-export approximations from a release build; the fault is inside V8 / cppgc internals during device-chooser setup.)

Regarding the Chromium question above: the trigger is an Electron-specific `webPreferences.partition` (named session), which has no web-page-settable equivalent in stock Chrome, so I can't reproduce it directly there. The crash itself is in the Chromium-layer device-chooser path, so a Chromium root cause is still possible.

### Testcase Gist URL

https://gist.github.com/boutetnico/cd2005b668f680b47abab2056b3fccc6

### Additional Information

The only difference between the crashing and non-crashing runs is a single `webPreferences.partition` value. In the gist, `main.js` calls `requestDevice()` from the main process via `webContents.executeJavaScript(code, /* userGesture */ true)` on `did-finish-load`; flipping the `USE_DEFAULT_SESSION` constant to `true` gives the non-crashing control case. No device or hardware is required — the crash happens while opening the device chooser.

Reproduced identically on:

| Electron | Chromium | Result |
| --- | --- | --- |
| 41.10.0 | 146 | SIGSEGV |
| 41.10.2 | 146 | SIGSEGV |
| 43.1.1 | 150 | SIGSEGV |

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.