-
Notifications
You must be signed in to change notification settings - Fork 22.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebHID API available in workers #36060
Conversation
@@ -8,7 +8,7 @@ status: | |||
browser-compat: api.HID.requestDevice | |||
--- | |||
|
|||
{{securecontext_header}}{{APIRef("WebHID API")}}{{SeeCompatTable}} | |||
{{securecontext_header}}{{APIRef("WebHID API")}}{{SeeCompatTable}}{{AvailableInWorkers}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
requestDevice() is not available in workers as it triggers a visible user prompt
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I've removed it from this page in the next commit.
@@ -29,6 +29,8 @@ _The `WorkerNavigator` interface doesn't inherit any property._ | |||
- : Returns the {{domxref("GPU")}} object for the current worker context. The entry point for the {{domxref("WebGPU_API", "WebGPU API", "", "nocode")}}. | |||
- {{DOMxRef("WorkerNavigator.hardwareConcurrency")}} {{ReadOnlyInline}} | |||
- : Returns the number of logical processor cores available. | |||
- {{domxref("WorkerNavigator.hid")}} {{ReadOnlyInline}} {{Experimental_Inline}} {{SecureContext_Inline}} | |||
- : Returns an {{domxref("HID")}} object providing methods for connecting to HID devices, listing attached HID devices, and event handlers for connected HID devices. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
connecting to HID devices that were already granted by user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added; I also changed the sentence a bit to improve the grammar generally. I ended up with:
Returns an {{domxref("HID")}} object providing methods for connecting to HID devices already granted permission by the user and listing attached HID devices, and event handlers for responding to HID devices connecting and disconnecting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought this was still a bit difficult structurally, and looked into it a bit, and had questions.
It looks to me like HID
does not provide a method "for connecting to HID devices", it only provides methods for listing devices and (in the window version only) requesting permission: https://wicg.github.io/webhid/#hid-interface.
It looks like the caveat ("already granted permission by the user") applies to listing devices, and does so for both the window and worker versions of the hid
property, but the window version doesn't mention it (https://developer.mozilla.org/en-US/docs/Web/API/Navigator/hid).
So perhaps here we could say something like:
Returns an {{domxref("HID")}} object, which enables a website to list HID devices to which the user has granted access, and be notified when the user agent connects to or disconnects from a HID device.
and in the window version:
Returns an {{domxref("HID")}} object, which enables a website to list HID devices to which the user has granted access, request access to a HID device, and be notified when the user agent connects to or disconnects from a HID device.
?
Also, is it pronounced "hid", like "a HID" or "aych eye dee", like "an HID"? The docs are inconsistent here. FWIW I would expect the former, and the spec seems to agree.
(aside, the redundancy in "HID device" aka "Human Interface Device device", is absolute nails on a chalkboard for me, but I suspect that ship has sailed.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that it's not "just" listing HID devices as web developer can connect to them once they get a HIDDevice. Maybe "communicating with HID devices user has granted access to previously". See https://developer.chrome.com/docs/capabilities/hid#open
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about this a bit, and ended up changing the text in both pages to:
...returns an {{domxref("HID")}} object providing methods for accessing HID device connections and events that fire when the user agent connects to or disconnects from a device.
I think saying it more generally like this does away with the need to nitpick about exactly what the methods are doing, and makes for a cleaner, easier-to-read sentence.
I have also checked the HID
object and method pages and tweaked their wording slightly to make sure it is clear that getDevices()
returns a list of connected devices that the user previous granted access to.
|
||
The **`WorkerNavigator.hid`** | ||
read-only property returns an {{domxref("HID")}} object providing methods | ||
for connecting to HID devices, listing attached HID devices, and event |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
connecting to HID devices that were already granted by user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as above.
The IDL indicates that it's only in This comment indicates that shared worker support is not coming yet? So I think it would be worth updating the macro to support this combination, and using it in these pages. |
Currently there supports 8 cases: 'window_and_dedicated': only in DedicatedWorker (and in Window)
'dedicated': only in DedicatedWorker
'window_and_worker_except_service': all workers but ServiceWorker (and in Window)
'worker_except_service': all workers but ServiceWorker (and no window)
'window_and_service': only in ServiceWorker (and in Window)
'service': only in ServiceWorker
'worker': All workers (and no Window)
null: (default) All workers (and in Window) I guess we could add the following all 6 (8 - 2) cases, or just the needed one? The following 6 (8 - 2) cases are: window+shared
shared
window+shared+service
shared+service
window+dedicated+service
dedicated+service
window only (omit from this)
none (omit from this) |
Or maybe extend a new {{Available}} macros in replace of {{AvailableInWorkers}} in the future, to represent the available scope of a feature, as there are many worklet scope has implemented or will implement, which may also need to express, too. |
@wbamberg good call Will. I have opened mdn/yari#11888 to add a new argument for the macro to support this particular case. You can now use I don't want to go and overboard and add cases for all web worker combinations. Seems like overkill for my requirements here. |
Thank you Chris! Do you know if this has percolated to production yet? I suppose we can't really merge this PR until then.
Yeah, I agree that it's enough just to patch this case. The proper solution would be to derive "available in" from the IDL, via webref. |
I was told it should have been deployed last night, but I tested it this morning and it is not there yet. It should be there by the time we get this one merged. |
Resolved via #36163. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 from me. Do you want to wait until mdn/browser-compat-data#24538 is out before merging this?
I think so, because the BCD explains that it is actually only SWs in webextensions that Chrome has WebHID enabled for. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Thank you :)
Given that mdn/browser-compat-data#24538 is merged, I’m going to merge this one, too. |
Description
The WebHID API is now available in web workers in Chrome 131. See this spec thread, the landing commit message, and the associated ChromeStatus entry.
This PR:
WorkerNavigator.hid
property.Motivation
Additional details
Related issues and pull requests