Hey Helmut, Since you have a plan for finishing the spec and tests, we don't need to pause the thread. Instead:
LGTM2 assuming spec and tests are merged before flipping the flag. It's great to see BiDi automation in practice here, Bluetooth was for a long time the my go-to example of a feature that was too complex to test using WPT, and that's no longer true! 🎉 On Mon, Nov 2, 2026 at 7:54 PM Helmut Januschka <[email protected]> wrote: > 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/CAARdPYexZnV5F4KLp8q_p-4JKQkRhB_BTWhho5q4jpKDiXQ-5A%40mail.gmail.com.
