It seems it is not related to Blink Bluetooth, it may be related to the Bluetooth pairing ui on ChromeOS settings:
https://cs.chromium.org/chromium/src/chrome/browser/chromeos/bluetooth/bluetooth_pairing_dialog.h?l=16

Assigning to Gio to find an owner.

Assigning to stevenjb who works on bluetooth settings.

This list comes from the Bluetooth Adapter code. We do not cache anything in the UI.

Though it's true that WebUI code doesn't cache anything I'm not sure the issue lies exclusively inside device/bluetooth: BluetoothAdapter::GetDevices will always return all known devices to the system: paired, devices, connected devices, etc.

If we are interested in only devices that are around then we should be adding devices to the list only when DeviceAdded/DeviceChanged() is called. We had a similar problem in Web Bluetooth's chooser and we changed to no longer calling GetDevices and relying on DeviceAdded/DeviceChanged to populate our chooser.

device/bluetooth also doesn't cache any devices itself; we just return whatever BlueZ tells us.

Assigning to rkc to help triage.

Can we not check the "IsPaired()" on the devices returned by GetDevices and ignore the ones that are not paired?

Re comment #9 - You mean ignore the devices that are paired? I believe we already do that.

hmm I wonder if this is a side effect of IsPaired no longer returning true. This is my theory:

1. Connect to a device (and thus mark it as trusted in <57)
2. Try to pair with the device and fail (which explains what the user saw the first time)
3. Wait for 57
4. Scan for devices.
5. Populate the list with all devices filtering out devices for which IsPaired is true.

Expected: Device connected to at 1 shouldn't appear.

What happens:

Device at 1 appears.

I believe this is because we marked it as trusted in <57. Before 57, IsPaired() would have returned true for this device thus it would have been filtered out of the list. But since we no longer return true when a device is just trusted the device shows up.

I think the solution would be to add both Trusted and Paired devices to the list in chrome:settings and filter out both Paired and Trusted devices from the "Add Bluetooth Device" list.

Currently the bluetooth API has no concept of 'trusted':

https://cs.chromium.org/chromium/src/extensions/common/api/bluetooth.idl?dr&l=40

This also seems like something we should be addressing at a lower level than the UI (we would probably have to fix the system tray UI code as well).

We already have the concept of 'paired' and 'connected', does the UI need to understand 'trusted' also?

Reading the original issue, the issue seems to be that we never forget devices we have once discovered. Not that we are not filtering out devices that are already paired or trusted.


I would postulate though that we should not be showing the user a list of all devices. We should be showing the user a list of devices as they get discovered *that* session - which is exactly what would happen if we use the DeviceAdded event (as Gio mentioned WebBT does) versus GetDevices.


The 'expected result' on the bug describes,
"The Add Device dialog should only display devices which are currently discoverable". I would suggest that we show devices in the add devices dialog for devices we *just* discovered in that session.

It does seem that is how it works on Android at least.

We would have to add that in the API level though. I am pretty sure that we want to support this use case:

1. User puts his device into discovery moved.
2. User opens the system tray or Settings.
3. Device shows up in list of devices to add.

If we rely only on bluetooth.onDeviceAdded events, IIUC the user would be required to reverse (1) and (2), which is a bad user experience.

On Web Bluetooth we only deal with Low Energy devices so we know DeviceChanged will be called a couple of times per second. Is that not the case for Classic devices?

@16: Should not be. We might get a device changed after the EIR comes through and we have more data about the device.

@15: So two things we should do.
a.) We should mirror the experience with Android. Whenever the user opens up the Add Devices dialog, we should start discovering.

b.) If discovery was already running when we call bluetooth.startDiscovery, we could have the API pick up the list of devices discovered during the existing session and send onDeviceAdded events for all of them.


Using GetDevices will always be problematic. What devices should GetDevices return exactly? Should it be devices just discovered? What about devices discovered about a minute ago? What about an hour ago?

It makes sense why Android just starts discovery again and shows the newly discovered devices. Unless we have good reasons not to go that way, we should do the same.

Is there ever a scenario where we would want bluetooth.getDevices() to return anything other than Paired + "recently discovered" devices, for some consistent definition of "recently discovered"?

i.e. I don't think the UI should be making this decision, I think we can leave it as it is and just fix the methods we expose to the UI (I'm not sure what the system tray uses exactly).

I'm not sure calling onDeviceAdded for all devices discovered in the current session makes things much better. If there is a previous long-running session then we are going to call DeviceAdded for devices that are no longer around.

Looking at bluetoothctl I see that we do get a Property Changed signal for classic devices because of the RSSI. So the solution might be to just add a device to the list if DeviceAdded or DeviceChanged has been called on that device. Hopefully we can add AdvertisementReceived and ClassicDeviceFound in the future.

The UI has changed in a recent chromebook update, so I thought I would post a new screenshot.

The problem remains unchanged.  Every device I've ever attempted to connect to remains in my "Unpaid Devices" dialog forever and cannot be removed.

Deleted: Screenshot 2017-07-22 at 8.59.18 AM.png 50.8 KB

	Screenshot 2017-07-22 at 8.59.18 AM.png 50.8 KB View Download

James now owns connectivity in Chrome OS UI, over to him.