Chromium

Oops, excuse me - in step 1 I meant navigator.bluetooth.getAvailability()

navigator.bluetooth.getAvailability() is intentionally limited in when it returns false. For example, it will still return true if Bluetooth is disabled. This is because a system capable of Bluetooth but with the adapter disabled can easily have the adapter enabled by the user as part of the navigator.bluetooth.requestDevice() flow. The idea is that a site can use getAvailability() to determine whether it should display Bluetooth-related functionality to the user or not. If it returns false it means that the system lacks any capability to use Bluetooth even if the user wanted take action to enable it.

Since the majority of Bluetooth capable devices are not using removable Bluetooth adapters the availabilitychanged event has not been implemented.

We have at least part of the infrastructure to detect when a Bluetooth radio is connected to the system in device/bluetooth/bluetooth_adapter_winrt.cc but it is currently only used to detect whether the radio is powered on or not but could be refactored to detect when a Bluetooth radio is added after BluetoothAdapterWinrt is initialized.

Due to the way BluetoothAdapter object lifetime is managed restarting the browser completely may not be necessary, as closing and reopening the tab should cause the BluetoothAdapterWinrt to be reinitialized unless there is another Chrome component keeping it alive.

Marking this issue Available to add it to our backlog.

Thank you for the information, I appreciate it. That explains some of the behaviour I've seen. Knowing what it's supposed to do, I guess the issue then becomes having no access to accurate state in circumstances where the modem is removable (and has been removed/reattached) without restarting the browser or the tab?

The availabilitychanged event would be a workable solution for my purposes, I think; I could rely on the initial assessment from navigator.bluetooth.getAvailability() and then capture any subsequent state changes via the event. Although in my opinion it would still be ideal if navigator.bluetooth.getAvailability() could always reflect if a Bluetooth modem was physically present or not.

In my case the desire is for an Electron app to be able to indicate to the user the current state of Bluetooth availability as part of its UI (whether it's present but idle, present and scanning, present and connected to something in app, or not present and unavailable).

At the moment, the only solution I've found for presence detection is to poke the Bluetooth API and see if I get an error back or not. If I get an error back such as "User cancelled the requestDevice() chooser" this implicitly means there is an issue with Bluetooth availability (specifically, this means "bluetooth WAS available but it's been removed" whereas "Bluetooth is unavailable" is the output if the app was started with no Bluetooth modem attached at all).

If the request works, then everything is OK, although it still does not update the output of navigator.bluetooth.getAvailability() either way.

This workaround is not ideal since if the app is started without Bluetooth modem attached, then it refuses any requests to the API even if the modem is subsequently reattached. It just insists there is no Bluetooth available. But if it's started with a Bluetooth modem present, then the modem can be removed/reattached and the API can be poked to check if it's currently there or not.

I'm not sure if the above information is helpful but thought I'd share just in case.

This issue was migrated from crbug.com/chromium/1430817?no_tracker_redirect=1

[Monorail components added to Component Tags custom field.]