LGTM1 on the condition that tests land soon; not a ship blocker, but within the next month would be best as others are looking at implementing WebBT and tests are the best guide.
Best, Alex On Wednesday, October 21, 2026 at 4:24:35 PM UTC-7 [email protected] wrote: > 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 > <https://webbluetoothcg.github.io/web-bluetooth/#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 > > [email protected] schrieb am Mittwoch, 21. Oktober 2026 um 17:35:54 > UTC+2: > >> *> 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/f3ec2cc3-9892-4a5b-8944-a20379b3d9adn%40chromium.org.
