Adding those tests would be great, I'm glad to hear it's feasible! Can https://github.com/whatwg/bluetooth/pull/672 be merged now that the spec has moved to the WHATWG?
On Tue, Oct 27, 2026 at 7:56 PM Alex Russell <[email protected]> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f3ec2cc3-9892-4a5b-8944-a20379b3d9adn%40chromium.org?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/CAARdPYc8qAnfiKdG4fUvBDqe8Eb6WUv%3DCGB%3DMyqngLnbzM3fDA%40mail.gmail.com.
