New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 770896 link

Starred by 25 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 1
Type: Bug



Sign in to add a comment

Support WebUSB in Apps and Extensions

Project Member Reported by reillyg@chromium.org, Oct 2 2017

Issue description

This bug tracks the task of enabling WebUSB in Chrome Apps and Extensions.

Open issues include:

1. Should WebUSB in a Chrome App use the same USB device permission store as normal web content or the one used by the chrome.usb API?
2. Creating a permission prompt in an app window may still require special code or it may just look weird because there is no address bar.
3. Are we okay with there not being a tab indicator on an app window that a USB device connection is active?
 
Status: Available (was: Untriaged)
We're very interested to see this happen as it would enable us to use WebUSB for the Hangouts Meet speakermic to use together with a Hotrod / CfM running in kiosk mode. We would prefer #1 to be similar to chrome.usb in the sense of being able to whitelist devices without requiring a user prompt
Cc: -scheib@chromium.org

Comment 4 by booger...@gmail.com, Apr 19 2018

Any update on this? It seems navigator.usb is exposed in the chrome app, but I can't test any further because the device picker does not show up. 
I recently investigated #2 above and we will indeed need special code in order to create a permission prompt on top of a Chrome App/Extension window.
Is there a branch with the current dev-status?

Any suggestions of how to speed this up? (e.g. specific research, assistance or possibly some incentive like a bounty) ?

(sidenote: agreeing with comment 2: white-list preferred)
Cc: rdevlin....@chromium.org roc...@chromium.org reillyg@chromium.org
 Issue 875861  has been merged into this issue.
What are the difficulties in exposing this for extension tabs?  It seems like then, there should be very little custom code required.  (I agree there are UX challenges with exposing this for background pages, popups, etc.)

I'd like to see if we can separate this out, and not block exposing this to extensions (which have fewer complications) on figuring out how it should work with Chrome Apps.
To do this only for extension pages hosted in tabs all we have to answer is how to word the request in the permission prompt as showing the chrome-extension://... URL is not going to be meaningful to the user. Do we have an existing example of those for other permissions? For chrome.usb.getUserSelectedDevices() we use the name of the Chrome App.
Could we show the extension name?  That's what we normally do in these cases, and is also what the site chip shows.

Attached is an example for an extension using navigator.geolocation.
Selection_028.png
9.9 KB View Download
Labels: -Pri-3 Pri-2
Cc: yllin@chromium.org itspeter@chromium.org yich@google.com
Labels: -Pri-2 -Type-Feature Pri-1 Type-Bug
We have to stick with the "deprecating" Chrome App instead of preferred "extension" before this fixed.
web bluetooth device selection works fine. what is blocking webusb device selection popup?
Capture3.PNG
10.6 KB View Download
It just needs to be implemented and tested.
any pointers for where to start implementation? I have c++ experience. 
Cc: -roc...@chromium.org rockot@google.com

Sign in to add a comment