Intent to Ship: Web Bluetooth: BluetoothRemoteGATTServer.maxWriteWithoutResponseSize

[Helmut Januschka]

Contact emails

hjanu...@gmail.com

Explainer

https://github.com/WebBluetoothCG/web-bluetooth/pull/672

Specification

https://pr-preview.s3.amazonaws.com/hjanuschka/web-bluetooth/pull/672.html#dom-bluetoothremotegattserver-maxwritewithoutresponsesize

Summary

Adds BluetoothRemoteGATTServer.maxWriteWithoutResponseSize, which reports the largest payload that writeValueWithoutResponse() can send in one ATT packet. A maxwritewithoutresponsesizechanged event notifies applications when Chrome observes the value change, allowing applications to size chunks without assuming a 20-byte limit. 

it depends on: https://chromestatus.com/feature/5138797158334464 and will be shipped together (it has 3 LGTM's; suprisingly mailing list only shows 2, but chromestatus shows 3). 

implementation: https://chromium-review.googlesource.com/c/chromium/src/+/7879985 

Bug: 40265040, 40686244, 40163619

Blink component

Blink>Bluetooth

Web Feature ID

web-bluetooth

Motivation

Web Bluetooth applications currently cannot determine the largest payload accepted by writeValueWithoutResponse() for an active GATT connection. They must hard-code the 20-byte default, use platform-specific heuristics, or probe with writes and handle platform-dependent failures or truncation. Exposing the usable payload size allows applications to chunk transfers correctly and use larger ATT MTUs for substantially better throughput.

Initial public proposal

https://github.com/WebBluetoothCG/web-bluetooth/issues/383

TAG review

No information provided

TAG review status

Not applicable

Goals for experimentation

None

Risks

Interoperability and Compatibility

Chrome would be the first implementation of this API. Firefox does not implement Web Bluetooth and Mozilla's position on Web Bluetooth is negative: https://github.com/mozilla/standards-positions/issues/95. Safari does not implement Web Bluetooth and WebKit's position is oppose: https://github.com/WebKit/standards-positions/issues/570. The change is additive, so existing sites are unaffected and sites can feature-detect the attribute. The value can become available at different times on different operating systems because their Bluetooth APIs expose ATT MTU information differently. The specification therefore defines the value as the user agent's current known maximum and fires the change event when the user agent observes an update.

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

Ergonomics

The API exposes the directly useful maximum write-without-response payload instead of the raw ATT MTU, so developers do not need to subtract the three-byte ATT Write Command header. The synchronous property avoids additional I/O and the event lets long-running transfers react when Chrome learns a larger value. Applications should read the property at the point of use or listen for the event because some platforms report the final value later than connection establishment.

Security

This adds a read-only numeric property and an event to an existing, permission-gated Web Bluetooth GATT connection. It does not grant access to additional devices, services, characteristics, or write operations. The value can reveal a small amount of information about the selected peripheral and platform Bluetooth stack after the user has granted device access and established a connection. Existing Web Bluetooth secure-context, user-consent, service allowlist, blocklist, and Permissions Policy protections continue to apply. The implementation is behind WebBluetoothMaxWriteWithoutResponseSize, which remains available as a kill switch after launch.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Low. This is strictly additive and behind a feature flag. Android WebView does not expose Web Bluetooth, so the new API is not available there.

Debuggability

The value is directly inspectable in DevTools as device.gatt.maxWriteWithoutResponseSize. Developers can use the Console, JavaScript debugger, and standard event-listener tooling for maxwritewithoutresponsesizechanged. No dedicated DevTools panel or protocol support is required.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No
Supported on Windows, macOS, Linux, ChromeOS, and Android wherever Web Bluetooth is available. Android WebView does not expose Web Bluetooth, so this is not supported on all six Blink platforms.

Is this feature fully tested by web-platform-tests?

No

Flag name on about://flags

No information provided

Finch feature name

WebBluetoothMaxWriteWithoutResponseSize

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/40265040

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

None beyond the platform Bluetooth APIs already used by Chromium's Web Bluetooth implementation: Android BluetoothGatt, CoreBluetooth, WinRT GATT, and BlueZ D-Bus.

Estimated milestones

Shipping on desktop	160
Shipping on Android	160
Shipping on WebView	160
Shipping on iOS	160

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

The API shape has converged in WebBluetoothCG PR 672 and the PR is approved. No further substantive changes are anticipated, but the PR must be merged before shipping.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5177569273053184?gate=6176654583005184

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFmjHKQ0ftKQn-37UikGJC2Zos%2BGyiOw7%2B5t-nx8NnRTckOUiQ%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Chris Harrelson]

Please file a Mozilla standards request for this feature. (No need to file a WebKit one, since they are opposed to WebBluetooth.)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFmjHKQBc%2BLCfBhiNC0mAhMDqV2RsvCnE7zvvBzXdg6d6XYC2A%40mail.gmail.com.

[Dan Clark]

> Is this feature fully tested by web-platform-tests?

> No

Could a WPT be added for this?

[Helmut Januschka]

Please file a Mozilla standards request for this feature.

Filed: https://github.com/mozilla/standards-positions/issues/1473

will update feature entry as soon theres a response.

Could a WPT be added for this?

Not today. Web Bluetooth WPTs drive fake peripherals through the bluetooth BiDi module in the spec’s Automated testing section, and neither those bluetooth.simulate* commands nor Chromium’s FakeCentral/FakePeripheral know anything about ATT_MTU. A fake device therefore always sits at the default, so there is nothing a test could assert.

Making it testable means an mtu on the GATT connection response plus a simulateGattMtuChange command, specced in that Automated testing section and implemented in the Chromium emulation layer. Happy to do all of it. How would you like it, land the automation commands in the spec first and have the WPTs as a shipping blocker, or ship on the current unit test coverage (web_bluetooth_service_impl_unittest.cc, bluetooth_gatt_bluez_unittest.cc, global-interface-listing) and track the WPTs as a follow-up?

cheers,
helmut

​