v157 · web bluetooth · live probe + generator
Listener migration map
"Everything on the device" was never a design, just the only option. Pick an event; the map answers which object hosts it after Chrome 157, proves the answer with a live prototype check for its onevent IDL handler in this browser, and writes the listener code for you.
Pick an event
The listener, generated
Why the split is right
A BluetoothDevice outlives any single connection; a BluetoothRemoteGATTServer is the connection (its connected flag is per-global, per-session). So device-lifetime events (gattserverdisconnected, advertisements) stay on the device, and connection-lifetime state (the negotiated write size) fires on the server. Before 157 the server could not host any event — it was the only interface in the hierarchy that did not extend EventTarget — so connection events had nowhere correct to go.
Migration is additive: no existing event moved. gattserverdisconnected did not move to the server — code listening on the device keeps working unchanged. What is new is that future connection-level events (and the already-shipped maxwritewithoutresponsesizechanged) attach to the server object.