Tests are done, and they're real WPTs, not Chromium-only ones. They drive the simulated peripheral over WebDriver BiDi, so any implementation with the Bluetooth automation module can run them.
That needed two upstream pieces, both up now: - spec text for the bluetooth.simulateGattMtuChange automation command, folded into the existing PR: https://github.com/whatwg/bluetooth/pull/672 (hope it will merge soon) - the testdriver/wptrunner plumbing for it: https://github.com/web-platform-tests/wpt/pull/64568 Chromium side: https://crrev.com/c/8701256 (emulation), https://crrev.com/c/8701565 (BiDi command), https://crrev.com/c/8702715 (the tests). hope that's the right path, still a noobie here, should i now try to get all PR's and CL's green/reviewed and after that, we continue with the LGTM collection? cheers, helmut Philip Jägenstedt schrieb am Mittwoch, 28. Oktober 2026 um 16:29:12 UTC+1: > 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/91c0972c-1c7a-498e-b5af-56af12d87e84n%40chromium.org.
