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/CAOMQ%2Bw8AwrfpA466_534mfNkrS8N_nYLWXC58_ghyrMWnHNtMQ%40mail.gmail.com.
