New issue
Advanced search Search tips

Issue 721296 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Chrome
Pri: 3
Type: Bug



Sign in to add a comment

usbdevice.open fails with "Access Denied"

Project Member Reported by dstockwell@google.com, May 11 2017

Issue description

Chrome Version: 57.0.2987.146
OS Version: 9202.64.0


Running:

let device = await navigator.usb.requestDevice({filters: []});
await device.open();


Results in:

=> Uncaught (in promise) DOMException: Access denied.


chrome://device-log contains the following for each 'open()' attempt:

Permission broker failed to open the device: org.freedesktop.DBus.Error.Failed: permission_broker/permission_denied:Permission to open '/dev/bus/usb/001/065' denied


and when the device is plugged in:

USB device added: path=/dev/bus/usb/001/065 vendor=5824 "Teensyduino", product=1159 "Serial/Keyboard/Mouse/Joystick", serial="562820", guid=308614ac-2f41-4bf2-a4c1-5a66a33b3ffe
 
Status: WontFix (was: Unconfirmed)
Based on the product name I am guessing that this is a composite device with CDC-ACM and HID interfaces. All of these will be claimed by the Chrome OS kernel and so the permission broker correctly denies Chrome access to the device.

Unless there an additional unclaimed interface (like the one created by this library: https://github.com/webusb/arduino/) then this is working as intended.
Status: Untriaged (was: WontFix)
In that case should the device be hidden from the device picker dialog?

side q: Are there plans to make such devices available as they are in the chrome.hid API?
Labels: OS-Linux
Status: Available (was: Untriaged)
We have a choice between two confusing behaviors:

* Acknowledge that the device has been connected but raise an error when the page tries to open the device.
* Do not acknowledge that the device has been connected at all.

I think the latter is more confusing as it makes the user believe the Chrome (or their computer) is not working at all while the former at least provides an error that points towards the cause of the problem.

(Adding Linux because missing udev rules cause the same failure.)
side a: There are no plans to do this as part of the WebUSB API. The replacement for chrome.hid would be a WebHID API.
Project Member

Comment 5 by sheriffbot@chromium.org, Jul 17 2017

Labels: Hotlist-Google
Status: WontFix (was: Available)

Sign in to add a comment