This appears to be a bug in Chrome. Concerning for web compat indeed.
To appreciate what's going on, open https://webrtc.github.io/samples/src/content/devices/input-output — In Chrome and Edge I see:
Audio input source: ✓ Default: Jan-Ivar Bruaroey's AirPods (Bluetooth) ▼
MacBook Pro Microphone (Built-in)
Jan-Ivar Bruaroey's AirPods
In Firefox and Safari I see:
Audio input source: ✓ AirPods ▼
MacBook Pro Microphone
Chrome and Edge default to a virtual "Default: ..." microphone that appears to (somewhat) track macOS's dynamic default — Firefox removed this duplicate "Default" microphone 3 years ago in bug 1404977.
I say "somewhat" because when I test this in Chrome, I notice:
- Once capture from "Default: ..." has started, Chrome switches dynamically only when AirPods turn off, not on.
- Track labels exposed to the page never update, which can be seen here.
- I experienced some serious non-recovering audio distortion a couple of times doing this.
When this was standardized years ago, web developers said they wanted full control over cameras and microphones, which unfortunately conflicts with browsers making smart decisions behind their back.
As a result, according to the spec, things like headset detection is up to sites to implement: https://jsfiddle.net/jib1/yohgar95/ — This works better with Firefox's permission model, which is per-device by default. Thus Firefox wouldn't always be able to implicitly auto-switch like Chrome did here.
And last, but not least, this auto-behavior in Chrome is limited to users of the "Default: ..." device. Try picking any other device in the first link in this comment, and the auto-behavior won't kick in, which means sites need to write all that JS I wrote in the last link anyway. Except because of Chrome, they're less likely to discover that they need to.