[web-bluetooth] Pull Request: Add BluetoothRemoteGATTCharacteristic.getMTU()

hjanuschka has just submitted a new pull request for https://github.com/WebBluetoothCG/web-bluetooth:

== Add BluetoothRemoteGATTCharacteristic.getMTU() ==
Hi folks 👋

I've been working on the Chromium implementation for exposing the
negotiated ATT MTU to web pages (crrev.com/c/7879985), and Reilly
rightly pointed out that this needs a spec change to go with it. So here
it is!

### What this adds

A new `getMTU()` method on `BluetoothRemoteGATTCharacteristic`:

```webidl
Promise<unsigned short> getMTU();
```

It resolves with the ATT_MTU negotiated for the connection that carries
the characteristic, i.e. the smaller of the local Host's transmit
ATT_MTU and the peer's receive ATT_MTU, as established by the Exchange
MTU procedure. When no exchange has happened it's the default of 23
octets.

### Why I want this

Today there's no way for a site to know how big a single write can be.
The practical pain is `writeValueWithoutResponse()`: if you hand it more
than `ATT_MTU - 3` bytes, the write either fails or gets silently
chopped depending on the platform, and the page has no way to tell ahead
of time. People end up hard-coding 20 (the old default payload) to be
safe, which leaves a lot of throughput on the table on modern devices
that happily negotiate 247+.

Exposing the MTU lets sites chunk their writes to fit a single PDU and
avoid unnecessary round trips. This has been asked for a few times over
the years (40265040 / 40686244 / 40163619 on the Chromium side).

### Open questions

- I put this on the characteristic to match where reads/writes live, but
  the MTU is really a per-connection property. Happy to move it to
  `BluetoothRemoteGATTServer` if folks feel that's a cleaner home.
- Naming: `getMTU()` vs an `mtu` attribute. I went with a method since
  the value is only meaningful while connected and resolving a promise
  felt more honest than a sync attribute that can throw/stale, but I'm
  not attached to it.

Implementation is wired up across BlueZ (Linux/ChromeOS), WinRT,
Android and macOS in the linked CL. Feedback very welcome -- this is my
first PR here, so tell me if I got the spec conventions wrong anywhere.

Thanks!


See https://github.com/WebBluetoothCG/web-bluetooth/pull/672


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 18 June 2026 19:35:26 UTC