Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Failed to send the report only during hot-plugged event, Duplicate of issue #65 #111

Open
JunzheFan opened this issue May 30, 2023 · 3 comments
Open

Failed to send the report only during hot-plugged event, Duplicate of issue #65 #111

JunzheFan opened this issue May 30, 2023 · 3 comments

Comments

@JunzheFan
Copy link

JunzheFan commented May 30, 2023 •
edited
Loading

I have been tested my device which is a headset connector with WebHID for a few days, I encountered a strange behaviour where I can not send the report using the device object received on the hot-plugged event, it throwed a DOMException with permisson not allowed. I tried a few workaround and found that if I set a 3 seconds delay then acquired the device, the output report can be successfully sent to device. Could it be the device is not actually ready for operation when the connect event fired like a race condition for re-granting permisson ? I assume the WebHID internally maintained a list of granted device, so the device object received on the connect callback argument is essentially the same object as the result returned from the navigator.hid.getDevices(), but it's strange I need to set a delay to get the device before can start doing operation, Below is code i used to showcase the situations mentioned above, thanks in advance

    navigator.hid.addEventListener("connect", async ({ device }) => {
      // Case 1
      // Failed to write the report, immediately send
      // if (!device.opened) {
      //   await device.open();
      // }
      // const data = new Uint8Array([0x6, 0x1, 0x0, 0, 0, 0, 0, 0]);
      // device.sendReport(data[0], data.slice(1, data.length));

      // Case 2 
      // Failed to write the report, send after a few seconds
      // if (!device.opened) {
      //   await device.open();
      // }
      // setTimeout(() => {
      //   const data = new Uint8Array([0x6, 0x1, 0x0, 0, 0, 0, 0, 0]);
      //   device.sendReport(data[0], data.slice(1, data.length));
      // }, 3000);
      
      // Case 3
      // if set a 2-3 seconds delay, then get the device, the report can be successfully sent 
      setTimeout(async () => {
        let [Device] = await navigator.hid.getDevices();
        if (!Device.opened) {
          await Device.open();
        }
        const data = new Uint8Array([0x6, 0x1, 0x0, 0, 0, 0, 0, 0]);
        Device.sendReport(data[0], data.slice(1, data.length));
      }, 3000);
    });
@nondebug
Copy link
Collaborator

nondebug commented Jun 7, 2023

Is anything logged in chrome://device-log or the developer console?

I agree this is strange. I don't think this is an implementation bug, this seems like a device error. If it were related to Chrome's permission model then it should have failed to open the device, but based on your description it sounds like open succeeded but sendReport failed.

@JunzheFan
Copy link
Author

JunzheFan commented Jun 12, 2023 •
edited
Loading

yes you are correct, the device can be successfully opened , I went to the chrome://device-log and got the following error message, and thanks to the error log I think I found where the problem was, my device has three top-level Application collections, during the hot-plugged event I found that WebHID only enumerated one of the collections which does not have the output descriptor set (I logged the device object received on the callback parameter using console.log(JSON.stringify(device.collections)); ) , it seems the other two collections which do have the output descriptor are missing and it's sub-device I am sending the report to. That do explain why I set a few seconds delay and acquire my device again can send the report successfully because in this case all three top-level Application collections are enumerated. But I am still not sure if the WebHID is triggering this event too soon ?
WXWorkCapture_16865342256653

@JunzheFan
Copy link
Author

JunzheFan commented Jun 18, 2023 •
edited
Loading

@nondebug HI matt, I found that my problem is essentially a duplicate of this issue reported two years ago, #65, since on Windows it seems not possible to wait for all topl level collections to be enumerated before firing the connect event, is there any update on the implementation of the 'devicechange' event you mentioned as sort of workaround in the issue

@JunzheFan JunzheFan changed the title Failed to send the report only during hot-plugged event Failed to send the report only during hot-plugged event, Duplicate of issue #65 Jun 18, 2023
@KhangxLi KhangxLi mentioned this issue Oct 24, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@nondebug @JunzheFan