*> Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* *> No*
Could a WPT be added for this? On Wednesday, October 21, 2026 at 8:29:53 AM UTC-7 Chris Harrelson wrote: > Please file a Mozilla standards request for this feature. (No need to file > a WebKit one, since they are opposed to WebBluetooth.) > > On Tue, Oct 20, 2026 at 11:22 AM Helmut Januschka <[email protected]> > wrote: > >> *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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFmjHKQBc%2BLCfBhiNC0mAhMDqV2RsvCnE7zvvBzXdg6d6XYC2A%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/b5eb3e19-cc9b-47b0-a3e7-f9ffd133a9e5n%40chromium.org.
