Issue metadata
Sign in to add a comment
|
webUSB stoped working for ALL HID devices
Reported by
lutz.ho...@gmail.com,
May 19 2018
|
||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3399.0 Safari/537.36
Steps to reproduce the problem:
1. navigator.usb.requestDevice({ filters: [] })
2. all HID device will not show any more, also non keyboard, mouse, touchpad devices
What is the expected behavior?
Only HID devices which have a standard driver should be filtered out.
There are a lot of special devices for the human interface which comply with the USB Device Class Definition
for HID Devices which do NOT have such a standard driver.
Example: We have here a lot of Motorola / Symbol / Zebra barcode scanners (DS6708). They can be set into different modes which comes up with different pids
- USB Keyboard HID: "productId": 4608
USBAlternateInterface {alternateSetting: 0, interfaceClass: 3, interfaceSubclass:1, interfaceProtocol: 1, interfaceName: null}
USBEndpoint {endpointNumber: 1, direction: "in", type: "interrupt", packetSize: 8}
- IBM Table-Top USB: "productId": 5120
USBAlternateInterface {alternateSetting: 0, interfaceClass: 3, interfaceSubclass: 0, interfaceProtocol: 0, interfaceName: null}
USBEndpoint {endpointNumber: 2, direction: "in", type: "interrupt", packetSize: 64}
- IBM Hand-Held USB: "productId": 4864
USBAlternateInterface {alternateSetting: 0, interfaceClass: 3, interfaceSubclass: 0, interfaceProtocol: 0, interfaceName: null}
USBEndpoint {endpointNumber: 2, direction: "in", type: "interrupt", packetSize: 64}
- Simple COM Port Emulation: "productId": 1536
USBAlternateInterface {alternateSetting: 0, interfaceClass: 3, interfaceSubclass: 1, interfaceProtocol: 1, interfaceName: null}
USBEndpoint {endpointNumber: 2, direction: "in", type: "interrupt", packetSize: 64}
Only in the first mode the scanner will be used with the system keyboard driver. But a keyboard driver is not able to handle all cases. I.e scanning post stamp barcodes, which hold binary data can not be done by handling keyevents. But also on ASCII data handling keyevents is insecure because in blink the is no way to differ between devices (real keyboard and scanner).
All the other modes work only with special native drivers which have to be installed first and are not available for all OSs. Also these drivers does not help on blink because they have their own non standard interfaces, which can not be accessed by blink APIs.
Reilly, in your posting https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/LZXocaeCwDw you substantiate this change with "... most USB devices fall into one of a number of standardized device classes for which there are already high-level APIs provided by the Web Platform".
But there is no navigator.hid API. And chrome.hid was only for chrome apps, which were dropped. So which API can we use instead?
What went wrong?
All non standard HID device are filtered out
Did this work before? Yes
Does this work in other browsers? N/A
Chrome version: 66.0.3359.181We Channel: n/a
OS Version: OS X 10.9.5
Flash Version: Shockwave Flash 30.0 r0
Up to now this is only a problem on windows version. MacOS and Ubuntu still work, also on canary builds. Will this stay like it is?
,
May 20 2018
Access to HID interfaces will be unavailable on all platforms starting with M-67.
,
May 20 2018
Is there a plan to make the HID interface useable again in chrome? Or is there still a way?
,
May 21 2018
The only solutions that will work in the short term are using the chrome.hid API or modifying the device so that it does not resent a standard HID interface class descriptor. I know that neither of these are particularly satisfying. Long term I would like to either standardize a WebHID API or return to allowing a subset of HID interface class devices to be accessible via WebUSB however at the moment we don't have the necessary filters in place to differentiate between devices we would like to expose to the web (like your scanners) and devices we do not want. There is a similar conversation happening around Bluetooth LE devices that present a HID profile. These are also blocked by the Web Bluetooth API. My hope is that any solution we come up with would unblock both of these use cases. Closing this issue as "WontFix" because this change is working as intended.
,
May 21 2018
Ok, looks like we have to go with electron & node.js for the moment. Unfortunately the result then can only be something for our internal use. For public small helpers like extensions it's no solution. thanks for your estimation anyhow. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by krajshree@chromium.org
, May 20 2018