This is happening with a Swiftpoint ProPoint.

Hi guys,

  I confirm similar issue with device that exposes HID over GATT service.

After some debugging here I've found that code exits in [1].

Error code is GattCommunicationStatus_AccessDenied.

That happens because we try to retrieve characteristics on a service that is already used by the OS.

Now, a workaround that makes service / characteristic enumeration proceed is to relax this line in case of access denied. Code proceeds and returns an empty list of characteristics [2].


[1] https://cs.chromium.org/chromium/src/device/bluetooth/bluetooth_gatt_discoverer_winrt.cc?g=0&l=236 

[2] https://cs.chromium.org/chromium/src/device/bluetooth/bluetooth_gatt_discoverer_winrt.cc?g=0&l=258

The issue needs to be tested using a Bluetooth Device. As ET-team doesn't have the above devices to test the issue. Hence, adding label TE-Hardware-Dependency.

Thanks...!!

Thanks, this issue should show up on any BTLE enabled HID Mouse which also has the Battery Service in the list of advertised services.

Thanks jracle@ for the advice on a workaround. We will find a BLE mouse and try it out.

I have done more testing and can confirm that the MacOS Chrome and Android Chrome perform as expected. 

Windows Chrome fails to proceed when there is a HID mouse gatt service as Windows OS will enumerate the device and the JS promise does not resolve.

You're welcome guys.

Please tell us if you need a device. Your team should have a few MX Master and MX Anywhere with BLE / Unifying connectivity.

Cheers

Hi guys, where are we on this issue?

It is blocking us (HID device makers)..

Gentle reminder..

Marking Untriaged so this doesn't fall off our radar again.

Thanks Reilly, I've done a CL this morning, but it doesn't show-up here..

Available at https://chromium-review.googlesource.com/c/chromium/src/+/1414850

Matt is looking at Julien's patch.

Thanks for the patch! We have an MX Master with dual Unifying/Bluetooth support. (I also have an MX Anywhere on my desk but it seems to be Unifying-only.)

I'm using these commands to request the device and get the battery service:

let dev = await navigator.bluetooth.requestDevice({ filters:[{name:'MX Master'}], optionalServices: ['battery_service'] });
await dev.gatt.connect();
let bs = await dev.gatt.getPrimaryService('battery_service');

On Chrome OS (73.0.3669.0, Pixelbook 'eve') we get the expected BluetoothRemoteGATTService with battery service UUID 0000180f-0000-1000-8000-00805f9b34fb.

On Windows 10 the promise returned by getPrimaryService does not resolve and eventually times out (as described above).

Tested again on Windows 10 against ToT with the patch provided in #13, the expected BluetoothRemoteGATTService is returned.