*Contact emails* [email protected] *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 <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EBluetooth%22> *Web Feature ID* web-bluetooth <https://webstatus.dev/features/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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* 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 <https://chromestatus.com/>. -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFmjHKQBc%2BLCfBhiNC0mAhMDqV2RsvCnE7zvvBzXdg6d6XYC2A%40mail.gmail.com.
