
Currently, calling any Web Bluetooth method prevents the frame from entering the back forward cache. This CL allows calls to navigator.bluetooth.getAvailability without preventing the frame from entering the cache. Other Web Bluetooth methods still prevent the back forward cache. Bug: 390566840 Change-Id: Ice43adfeff85b58087fbcec55c55b83e345a40fd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6190377 Reviewed-by: Jack Hsieh <chengweih@chromium.org> Commit-Queue: Matt Reynolds <mattreynolds@chromium.org> Reviewed-by: Fergal Daly <fergal@chromium.org> Cr-Commit-Position: refs/heads/main@{#1422660}
Web Bluetooth Service in Content
This directory contains the implementation of the Web Bluetooth specification
using the Bluetooth abstraction module implemented in //device/bluetooth
. See
the Bluetooth Abstraction README for more details on the cross-platform
implementation of Bluetooth in Chromium.
This service is exposed to the Web through the Blink Bluetooth module, which accesses the Web Bluetooth Service through Mojo IPC. For more details, see the Web Bluetooth Blink Module README.
Web Bluetooth Permissions
The legacy permissions system is implemented by bluetooth_allowed_devices.h
,
which is created per origin.
The new permissions system is implemented by providing an implementation for the
//content/public/browser/bluetooth_delegate.h
interface. In Chrome and
WebLayer, the implementation of this interface is provided by
//components/permissions/bluetooth_delegate_impl.h
which forwards permission
queries to //components/permissions/contexts/bluetooth_chooser_context.h
. This
class uses //components/permissions/object_permission_context_base.h
as the
base. This base class is also in use by other device APIs, like WebUSB. The new
permission system enables Web Bluetooth permissions to be persistent and to be
exposed in the settings UI for users to manage more easily. For more details on
the new permissions system, see the Web Bluetooth Persistent Permissions
design document.
Secure Characteristics
The Bluetooth client implementation will authenticate (i.e. pair) when needed. This allows clients to read values that do not require pairing without going through the pairing process. In practice this means that pairing will be initiated during a read/write operation. Some operating system Bluetooth implementations (like macOS and Android) do this transparently for the application. Other OS's (like Windows and Linux/BlueZ) need to explicitly pair when a read/write fails due to an authentication error.
Testing
The Web Bluetooth Service is primarily tested using Blink Web Tests and Web
Platform Tests. These tests are found in
//third_party/blink/web_tests/bluetooth
and
//third_party/blink/web_tests/external/wpt/bluetooth
. There is currently an
ongoing effort to refactor the Web Bluetooth tests using the legacy
BluetoothFakeAdapter test infrastructure to use the new FakeBluetooth
Test API. For more details, see the Web Bluetooth Web Tests README and the
Web Bluetooth Web Platform Tests README.
TODO(crbug.com/40426301): Update this document when the remaining tests have been submitted to W3C Web Platform Tests.
The tests are run using content_shell
, which fakes the Bluetooth related UI
and the new permissions system. For more details, see the following files in
//content/shell/browser/web_test
:
- fake_bluetooth_chooser.h
- fake_bluetooth_delegate.h
- fake_bluetooth_scanning_prompt.h
- web_test_bluetooth_adapter_provider.h
- web_test_first_device_bluetooth_chooser.h
Resources and Documentation
Mailing list: web-bluetooth@chromium.org
Bug tracker: Blink>Bluetooth
- Web Bluetooth specification
- Bluetooth Abstraction README
- Web Bluetooth Blink Module README
- BluetoothFakeAdapter
- FakeBluetooth