Device chooser for WebUSB

[gniezen]

Is your feature request related to a problem? Please describe.
Electron has a chooser for Web Bluetooth (#5565), but no chooser for WebUSB. Even if there is only one device, WebUSB still requires the chooser to be used, currently resulting in a DOMException: No device selected when calling navigator.usb.requestDevice().

WebUSB has been available (without an experimental flag) since Chromium 61.

Describe the solution you'd like
Implement a chooser window like the one in Chromium (see https://cs.chromium.org/chromium/src/chrome/browser/usb/web_usb_chooser.h) to request permission from a user to access a USB device.

Describe alternatives you've considered
node-usb is an alternative that can be used, but it is barely maintained. WebUSB is well supported by the Chrome team and seems to be the way forward.

Additional context

• Link to spec: https://wicg.github.io/webusb/
• Screenshot:
  

[welcome]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[MarshallOfSound]

Implement a chooser window like the one in Chromium (see

Just commenting here that we won't implement any UI for this, if someone gets to implementing this it would follow the same pattern as the bluetooth API which emits an event with the possible bluetooth devices and leaves the UI up to individual apps.

[reillyeon]

Let me know if you have any questions about enabling this. Right now WebUSB isn't hooked up in the easiest way for content embedders but we are refactoring it right now so it should get better.

[MarshallOfSound]

@reillyeon Yeah I took a look at this and it's not hooked up to webcontents observer like blueooth is. Might just wait for a refactor 😄

[Venryx]

Any update on this? Would be helpful for the Electron app of a website I'm building which needs to get the output from a TRNG (true/hardware random-number-generator) usb device.

Like mentioned above, there are some NodeJS alternatives, but it would be nice to use the web standard if possible since it means the USB-access code can be shared between the Electron app and the web-only version.

[reillyeon]

While you are waiting for this you can use webusb which is a polyfill of WebUSB on top of the Node-specific usb package.

[dilushan]

Any update on this issue? Seems NW.js fixed this over a year ago
nwjs/nw.js#6500

[rampageservices]

Hi @MarshallOfSound @reillyeon Would you kindly take a look at this and let us know if the refactor has taken place at this point to enable this to go ahead? I checked the USB code in the chromium browser folder and I did not see a WebContentsObserver. Also, I did not see a ticket open to implement this on bugs.chromium.org. I'd like to open a ticket but I do not have your expertise on this matter. Your guidance would be appreciate so that we can get this working in electron.

[reillyeon]

The refactoring in Chromium is tracked by issue 991759. This unblocks a whole bunch of things that will help embedders like Electron as well as Headless Chrome and Android WebView.

[gniezen]

@reillyeon Looking at the issue you linked to, am I understanding correctly that Web Serial and WebHID are hooked up to WebContentsObserver?

[nondebug]

I don't believe that either API registers as a WebContentsObserver. They do both access WebContents, but only to update whether or not there are open connections to Serial or HID devices.

[reillyeon]

As a subclass of content::FrameServiceBase the content::HidService class implementing the browser-process side of the WebHID API is a content::WebContentsObserver. For the WebUSB API, instances of WebUsbServiceImpl are owned by a UsbTabHelper which is a content::WebContentsObserver.

[robertguyser]

Sorry to bring back this dead issue, but there is no other real discussion of it anywhere on the internet. I am attempting to use the webusb polyfill method, and when I try to call requestDevice(), it disconnects the debugger and I do not get a chooser. I have manually specified a device, but when it attempts the requestDevice, it crashes.

With the polyfill is there a way to over-ride and select the device manually or was the suggestion above of using a polyfill library misguided? Thank you in advance for any advice.
This is the script to easily recreate the issue:
https://github.com/thegecko/webusb/blob/master/examples/selector.js

[reillyeon]

@robertguyser this issue is not dead but your question is off-topic. For issues with thegecko/webusb please use that repository's issue tracker.

[NessDan]

Any update on this? Looking to use Electron to talk to a piece of hardware I'm making, would love to use navigator.usb as described here.

[ehte92]

Any updates here? Working on an electron app which connects to a mobile device and would like to use the WebUSB api for it.

[jjeff]

I've been looking into using the WebHID API available in Chromium 89 (Electron 12) and later. It looks like this inherits the same permission problem as WebUSB. If anyone wants to kill two birds with one stone, we could get an API similar to webContents.on('select-bluetooth-device') for both navigator.usb.requestDevice() and navigator.hid.requestDevice(). Maybe this could all be consolidated into webContents.on('request-device')? Or not.

[HundredChaos]

ah shit here we go again

…

On Sun, Jul 11, 2021 at 12:18 PM Jeff Robbins ***@***.***> wrote: I've been looking into using the WebHID <https://web.dev/hid/> API available in Chromium 89 (Electron 12) and later. It looks like this inherits the same permission problem as WebUSB. If anyone wants to kill two birds with one stone, we could get an API similar to webContents.on('select-bluetooth-device') <https://www.electronjs.org/docs/api/web-contents#event-select-bluetooth-device> for both navigator.usb.requestDevice() and navigator.hid.requestDevice(). Maybe this could all be consolidated into webContents.on('request-device')? Or not. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#14545 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR3X2BS43BMQXXURBMC6JKLTXG75ZANCNFSM4FUM25JQ> .

[ghost]

+1 on this

It should be fairly trivial to implement the permission and device chooser now that we have webContents.setDevicePermissionHandler through #30213 and #22478

[7ombie]

How will access to protected interface classes work? It seems ok to ignore that aspect of the spec entirely. Same for the device blocklist.

I would like to use Electron for an app the supports discontinued (non-class-compliant) MIDI devices and soundcards, so would really appreciate WebUSB support.

[reillyeon]

I have a work-in-progress Chromium change which does the refactoring necessary for //content embedders like Electron to support WebUSB. In that change the new UsbDelegate interface has an AdjustProtectedInterfaceClasses method which Electron can override to control how that part of the specification is implemented.

I unfortunately don't have cycles to work on this right now (which is why I uploaded the patch as WIP). If someone wants to take this on I am happy to do code reviews.

[7ombie]

Thank you, @reillyeon. Much appreciated. It's not something I would be competent to take on.

I guess I can just use the Node USB library for now (I believe there's a WebUSB shim), and move to WebUSB once it's ready. It's just a hobby project, so it's not the end of the world if it gets delayed. The Node USB libraries don't support isochronous transfers :(

Thanks again.

[nondebug]

The Chromium refactor is complete. Content embedders should implement the UsbDelegate interface.

https://source.chromium.org/chromium/chromium/src/+/main:content/public/browser/usb_delegate.h

[gniezen]

@nornagon Since the Chromium refactor is compelete, I guess the "blocked/upstream" tag can now be removed?

[cikichen]

Is there a conclusion? If not, I'll ask again later

[parkerlreed]

Also very interested in this.

[rampageservices]

I have been monitoring this issue for a few years now. It appears all the backend work in Chromium has been completed. Now the next step is for someone to implement the functionality in Electron.

[penx]

I'm getting

attempt to claim a USB device interface has been blocked because it implements a protected interface class.

and

The requested interface implements a protected class.

when trying to claim a USB Audio device.

I see there was discussion above regarding AdjustProtectedInterfaceClasses by @reillyeon and @7ombie but I'm not sure if the ability to override which classes are considered "protected" was included in #36289 by @jkleinsc.

I can see AdjustProtectedInterfaceClasses in the following file:

https://github.com/electron/electron/blob/main/shell/browser/usb/electron_usb_delegate.cc

...but I don't see if this translates to something I can access/configure.

Has this been implemented, but I'm missing how to set it? If not, should I open a new ticket/feature request?

[reillyeon]

ElectronUsbDelegate::AdjustProtectedInterfaceClasses() just seems like a verbatim copy of the version from ChromeUsbDelegate. It'll need to be updated to either give developers control or just clear the list of protected interface classes entirely.

[penx]

Ah that makes more sense, I had been looking at this:

// Isolated Apps have unrestricted access to any USB interface class.

https://github.com/electron/electron/blob/a26343f3e084028b920a7ea44e6b221350e3546c/shell/browser/usb/electron_usb_delegate.cc#LL155C6-L155C20

And was assuming that referred to an Electron Context Isolation. Thanks for clearing that up 😄

From my understanding of that comment, and the one shortly below it, if I want to use WebUSB with an audio device, Isolated Web Apps (still in development) and Chrome Apps (Chrome OS only?) are the two options I have right now (edit: perhaps neither are an option right now).

[reillyeon]

if I want to use WebUSB with an audio device

If you don't mind me asking, why is that something you want to do?

[penx]

if I want to use WebUSB with an audio device

If you don't mind me asking, why is that something you want to do?

I have a usb audio interface. The manufacturer discontinued the software for newer versions of macOS. In order to set things like input gains, input selection, or even set volume, I need to send control messages to the hardware.

I’d prefer to do this with a web interface as it’s what I’m used to and I can port it easily.

[penx]

fwiw I can use electron plus node-usb to work around this. But was gonna have another go at using WebUSB now that this feature is in

[hinaple]

Any updates here?

[johnnytolengo]

Anyone has the WebUSB already working? In my case the "navigator.serial.requestPort()" is not showing up the devices list on Ubuntu.