Closed besty99 closed 2 years ago
I think this is an implementation bug and not tied to whether the exception is a DOMException
or not. There's a refactoring happening within Chromium to make sure that the "script state" from where the Promise
was created is provided when constructing the DOMException
and that might help improve the diagnostic messages.
Can you point me to where you found this "feature of DOMException
" documented?
I think this is an implementation bug and not tied to whether the exception is a
DOMException
or not. There's a refactoring happening within Chromium to make sure that the "script state" from where thePromise
was created is provided when constructing theDOMException
and that might help improve the diagnostic messages.Can you point me to where you found this "feature of
DOMException
" documented?
Well, after you reply, we just tried to raise DOMException
on firefox, it's really chrome's bug.
But the real problem we found is that, if i use webusb in web worker. there is a really rare case that the chrome will report Unable to claim interface
. Here is the detail
Mainthread first open and claimInterface of usbDevice (because mainthread also need something from USB device) Then prepare data, releaseInterface, and close. deliever it to worker thread. Worker thread then open and claimInterface and transfer data to usbDevice.
less then 1‰ possibility we found user will encounter "unable to claim Interface". The wired part is that if the problem happen, it can never recover unless rebooting the PC.(I didn't witness. But someone says they can recovery if they just restart chrome, someone says only rebooting works )
not recovery even i try another domain and claimInterface. not recover even i unplug and then plugin the phone. not recover even i change another phone. (I witness this)
Can you file a separate Chromium issue for the issue you are having and include information about the platform? Once the Promise
returned by releaseInterface()
resolves another context should be able to claim it.
Can you file a separate Chromium issue for the issue you are having and include information about the platform? Once the
Promise
returned byreleaseInterface()
resolves another context should be able to claim it.
Sorry, i didn't make it clear. We have 2 problems.
Question 2 is chrome bug, i will file it in another place.
But the question 1 is strange. Because we checked all of our codes. All calls of releaseInterface
is awaited. So we're out of clue
Here is the log. Just like i said, if someone encounter this problem, then he will 100% reproduce this problem unless rebooting the PC. Here is log the second time my user encounter this problem We're pretty sure all "releaseInterface" are awaited.
I am going to close this issue because it is not a specification issue, but an implementation issue (or multiple issues). We've filed Chromium issue 1318609 to track the claimInterface()
failure. Please comment on that bug with whether you are on Windows or another platform as I have a theory which would explain the problem if it only happens on Windows.
I found that after I failed to execute device.claiminterface(), the exception I got was "Uncaught (in promise) DOMException: Unable to claim interface." This makes it impossible for me to accurately obtain the number of lines reported by the code. Just like:
In this code, if there is an error in the execution of this.device.claiminterface(). In the browser, the error I showed was pointing to line 7 instead of line 5. I found that this is a feature of DOMException. If it is an Error type, the browser can point to the correct location.