
Following up on https://chromium-review.googlesource.com/c/chromium/src/+/4567353/comments/67bd2f0d_b10f9056 Add back DanglingUntriaged into the name of this trait. Keep the name consistent with other traits. Change-Id: I2702f843d9e81b87656ca31fd4c9ba19943d44d9 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4675808 Commit-Queue: Pâris Meuleman <pmeuleman@chromium.org> Owners-Override: danakj <danakj@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/main@{#1172247}
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/chooser_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(https://crbug.com/509038): 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