Please also notice that although mouse is connected and working, device.gatt.connected returns false (observed while debugging JavaScript code).

We might enter a separate issue for that..

Thank for filing this bug Julien. Can you include Chrome logs as described at https://www.chromium.org/developers/how-tos/file-web-bluetooth-bugs?

TLDR:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --enable-logging --vmodule=*bluetooth*=9
tail -f ~/Library/Application\ Support/Google/Chrome/chrome_debug.log 

Here are btmon and dbus-monitor traces (on Chrome OS dev peppy)

Deleted: btmon.txt 357 KB

btmon.txt 357 KB View Download

Deleted: dbus-monitor.txt 78.1 KB

dbus-monitor.txt 78.1 KB View Download

Seems this is all platforms? 

I guess it indeed because the connection is shared so disconnecting the ACL would cause others profiles to be disconnected as well. In BlueZ it is possible to register the client role with GattProfile1 agent, this let the stack know what profiles the clients are interested and disconnect only if there are no clients or no profile matching, perhaps we should introduce a similar mechanism for requestDevice using the UUIDs passed in filter to do the matching.

@Vincent, I observe it only on Chrome OS. See bug description (sorry I didn't apply proper bug template apparently). On Mac, due to https://bugs.chromium.org/p/chromium/issues/detail?id=630581 I cannot check behavior.

@Luiz, that could be great. I'm not familiar with BlueZ, but seems a good point. Here we have a mouse with custom profiles and standard ones, including HID over GATT. I can give more information on that.

I'm also able to reproduce this issue with paired MX Anywhere 2 BLE mouse on Chrome OS 53.0.2785.36.

See bluetoothd logs when I close chrome tab that was connected to the mouse:

bluetoothd[28100]: src/device.c:device_set_auto_connect() E7:E5:BE:FE:D8:AE auto connect: 0
bluetoothd[28100]: src/adapter.c:remove_device_complete() E7:E5:BE:FE:D8:AE (2) removed from kernel connect list
bluetoothd[28100]: src/adapter.c:dev_disconnected() Device E7:E5:BE:FE:D8:AE disconnected, reason 2
bluetoothd[28100]: src/adapter.c:adapter_remove_connection() 
bluetoothd[28100]: plugins/policy.c:disconnect_cb() reason 2
bluetoothd[28100]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr E7:E5:BE:FE:D8:AE type 2 status 0xe
bluetoothd[28100]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
bluetoothd[28100]: src/device.c:device_bonding_failed() status 14
bluetoothd[28100]: src/adapter.c:resume_discovery() 
bluetoothd[28100]: src/device.c:att_disconnected_cb() 
bluetoothd[28100]: src/device.c:att_disconnected_cb() Software caused connection abort (103)
bluetoothd[28100]: src/device.c:attio_disconnected() 
bluetoothd[28100]: profiles/input/hog.c:attio_disconnected_cb() HoG disconnected
bluetoothd[28100]: attrib/gattrib.c:g_attrib_unref() 0x204ebb0: g_attrib_unref=1 
bluetoothd[28100]: src/gatt-client.c:btd_gatt_client_disconnected() Device disconnected. Cleaning up.
bluetoothd[28100]: src/device.c:att_disconnected_cb() Automatic connection disabled
bluetoothd[28100]: attrib/gattrib.c:g_attrib_unref() 0x204ebb0: g_attrib_unref=0 

Great, thanks for testing!

I'm experiencing a much different issue when I try to repro this.

I connected an apple mouse to my Chromebox
I enabled the Web Bluetooth flag
I visited that Github page
I click the get bluetooth device information button
I select the Apple mouse and click Connect
I get this: 

"Requesting any Bluetooth Device...
Connecting to GATT Server...
Getting Device Information Service...
Argh! NotFoundError: Service not found in device."

I click the X to close the tab, and my Chromebox appears to reset. The screen goes black for a few seconds, and then it comes back and I get the "chrome did not shut down properly, restore". The mouse is still connected and works fine tho.

#12: Could you go to chrome://crashes/ and send the Crash ID?

According to https://bugs.chromium.org/p/chromium/issues/detail?id=636078, Dual mode devices are currently not being handled correctly by Chrome OS. See Design Doc at https://docs.google.com/a/chromium.org/document/d/1TDR90wWbsBS3rftjyPcETpvX94ulAtxpjFZzwQ94qKU/edit?usp=sharing

Even these devices are BLE only, I believe it is worth checking how it is going to impact this bug.

@luiz If I understand correctly registering services with GattProfile1 would mean that bluetoothd would auto connect to any devices matching the profile. That seems undesirable. It's a shame BlueZ doesn't do reference counting for connections (both Android and macOS do). There is even a TODO in the code to solve this once BlueZ implements reference counting:

https://cs.chromium.org/chromium/src/device/bluetooth/bluez/bluetooth_device_bluez.cc?q=bluetooth_device_bluez.cc&sq=package:chromium&dr&l=560

GattProfile1 is used to tell the stack which profile shall be connected automatically for devices connected in the past using passive scanning, so in case there is a link loss it can recover much quicker even though web bluetooth don't seem to have anything similar in this regard.

Note that although this is not exactly working as a refcount it can be used in such a way that causes bluetoothd to know if the connection should be disconnected once the GattProfile exits, but obviously this does not work if Device1.Disconnect is called since that uses GAP procedure to disconnect the ACL it has nothing to do with GATT.

So Im currently debating between adding refcount to ConnectProfile, which we would have to add support for GATT, or adding a entire new API which have been in use in automotive:

https://github.com/Vudentz/BlueZ/blob/service_api/plugins/service.c

With the service API we would have much more control over each services so we could introduce refcounting with Service1.Connect and don't mess around with ConnectProfile which is a quite limited API.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f1da372348cf570d8f1bb538b16d0ec3d47fbeb3

commit f1da372348cf570d8f1bb538b16d0ec3d47fbeb3
Author: ortuno <ortuno@chromium.org>
Date: Mon Sep 26 00:40:49 2016

bluetooth: Leak connections to paired devices

In order to avoid terminating connection to devices other parts of the
system might still be using we leak connections to paired devices.

BUG=630586

Review-Url: https://codereview.chromium.org/2357083002
Cr-Commit-Position: refs/heads/master@{#420865}

[modify] https://crrev.com/f1da372348cf570d8f1bb538b16d0ec3d47fbeb3/device/bluetooth/bluetooth_device.h
[modify] https://crrev.com/f1da372348cf570d8f1bb538b16d0ec3d47fbeb3/device/bluetooth/bluez/bluetooth_device_bluez.cc

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot