LGTM3. But let us know if landing the specs and tests gets blocked for some reason - worst case we can approve proceeding based on the PRs, but we should make an honest effort to try to get the PRs landed.
On Wed, Nov 4, 2026 at 11:16 AM Philip Jägenstedt <[email protected]> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYexZnV5F4KLp8q_p-4JKQkRhB_BTWhho5q4jpKDiXQ-5A%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/CAFUtAY9SpxeMsK0o7Pst_xuk1sYJPXK7Fsx0P4DS-FaVHycrHg%40mail.gmail.com.
