Intent to Prototype and Ship: WebUSB SameObject

93 views
Skip to first unread message

Jack Hsieh

unread,
Feb 25, 2022, 8:27:58 PM2/25/22
to blin...@chromium.org

Contact emails

chen...@chromium.com


Explainer

None


Specification

https://wicg.github.io/webusb/#device-usage

https://github.com/WICG/webusb/pull/212


Summary

Make USBConfiguration, USBInterface, USBAlternateInterface, and USBEndpoint instances returned by the accessors on USBDevice === comparable.


Blink component

Blink>USB


Motivation

It is helpful for WebUSB to have USBConfiguration, USBInterface, USBAlternateInterface, and USBEndpoint instances returned by the accessors on USBDevice === comparable. We have seen this requirement reported by developers from https://crbug.com/1274922 and a positive signal from a Node.js polyfill (https://github.com/thegecko/webusb).


TAG review

The change is trivial enough to waive a TAG review requirement.


TAG review status

Not applicable


Risks



Interoperability and Compatibility

This change only adds the `===` compatibility to related objects and data structures while behaviors of the existing WebUSB APIs remain the same. Developers who don't rely on this `===` compatibility wouldn’t notice a thing with this feature rolling out behind the scenes, and so we believe the compatibility risk to be minimal.


Signals from other implementations (Gecko, WebKit): 


Gecko: No signal


WebKit: No signal


Web developers: https://crbug.com/1274922.


Other signals: The Node.js polyfill for WebUSB (https://github.com/thegecko/webusb) already implements these accessors this way.



Debuggability

No specific DevTools changes are required. This feature only changes the internal behavior of existing WebUSB JS methods.

Note that exposing DevTools debugging support for device-access APIs (WebUSB included) is discussed at https://bugs.chromium.org/p/chromium/issues/detail?id=1142566.


Is this feature fully tested by web-platform-tests?

Yes. This feature will be fully tested at https://wpt.fyi/results/webusb


Flag name

None


Requires code in //chrome?

False


Tracking Bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1274922


Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5769668454252544


This intent message was generated by Chrome Platform Status.


Mike Taylor

unread,
Feb 28, 2022, 9:29:14 AM2/28/22
to Jack Hsieh, blink-dev
This seems like a useful ergonomics addition. LGTM1.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADQ2FkQK7ZWqUJ3PrVSKPPoxemNoORHM5aT2ymGU6qurOaJ%2B0g%40mail.gmail.com.


Yoav Weiss

unread,
Feb 28, 2022, 9:41:54 AM2/28/22
to Mike Taylor, Jack Hsieh, blink-dev
LGTM2

I agree that the probability of developers relying on these objects not being === comparable today is slim.

Worth noting that given Gecko's and WebKit's overall negative position RE WebUSB, they are unlikely to have a strong opinion about this change.

Chris Harrelson

unread,
Feb 28, 2022, 10:50:22 AM2/28/22
to Yoav Weiss, Mike Taylor, Jack Hsieh, blink-dev
Reply all
Reply to author
Forward
0 new messages