Re: [web-bluetooth] Handling readValue from protected/secure characteristics of not-yet-PIN-paired devices is underspecified (#563)

...oy, I think you may be right. I think this makes perfect (annoying) sense. 

His code is a bit more deeply chained than I'd ever write, so it's hard to trace where the exception is thrown (the second request?)... It's also a bit more confusing than I expect, because the "NetworkError: Authentication canceled" error message does not suggest the cause was something *other* than multiple requests in flight. I also sometimes (rarely) see a "DOMException: Connection already in progress.", which is more informative. The exception is also not immediately raised on the second call to `readValue`, which I do not understand. I guess chrome must not check whether one is in flight before queueing the task internally? 

It sounds to me like the *correct* fix is going to take a promise queue, which is a headache, but entirely possible. I'll close the issue as soon as I understand what you mean by an implementation bug in windows. Is it documented that windows doesn't support multiple parallel pairing requests? Hmmm. If so, would it make more sense for it to be up to the browser or the client code to make sure there's only one pairing request at a time?

-- 
GitHub Notification of comment by ariccio
Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/563#issuecomment-942794343 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 13 October 2021 23:26:18 UTC