Here's a bit of code to explain context:


        navigator.bluetooth.requestLEScan({
          filters: [{manufacturerData: 0x004C}],
          options: {
            keepRepeatedDevices: false,
          }
        }).then(_ => {
          navigator.bluetooth.addEventListener('advertisementreceived', event => {
              // I want to able to connect to each of them in one single operation
              // or to construct an array of all devices...
              // That's why this below wouldn't work. 
              event.device.requestGatt().then(...)
            }

Calling requestGatt() several times within one turn should coalesce them into a single bubble.

Steps to reproduce:
1. Go to https://beaufortfrancois.github.io/sandbox/web-bluetooth/multiple-request-devices/index.html
2. Click "Request device three times sequentially" button
3. Bluetooth chooser shows up

What happens:

index.html:11 Uncaught (in promise) DOMException: Must be handling a user gesture to show a permission request.
(anonymous) @ index.html:11
index.html:12 Uncaught (in promise) DOMException: Must be handling a user gesture to show a permission request.
(anonymous) @ index.html:12

What should happen:

Filters should be combined into a single picker.

I'd like to understand what type of combining you propose/expect. The user will select only one device, what should be returned to multiple requests?

If the requests are mutually exclusive, then we could fulfill the single request that matches, and reject others. If requests overlap... we fulfill all that match?

I'm unsure if we should do this for developers. It doesn't seem to be a common need for requestDevice. In your earlier explanation for device.requestGatt I think it makes more sense.

I'm also concerned that code that accidentally calls requestDevice multiple times (e.g. due to incorrectly double event handlers or something) will then have multiple chains of follow up actions, connecting multiple times and performing application actions multiple times. With only a single active requestDevice these actions would need to be explicitly done.

I'm biasing towards keeping the implementation simpler.

Sorry my comment #2 is wrong. Let's discard it.

navigator.bluetooth.requestDevice called multiple times in the same loop should simply consider the last one and discard previous ones.

In other words,

        navigator.bluetooth.requestDevice({ filters: [{ name: 'a' }] });
        navigator.bluetooth.requestDevice({ filters: [{ name: 'b' }] });
        navigator.bluetooth.requestDevice({ filters: [{ name: 'c' }] });
     
Should show a bluetooth chooser with filters name 'c' AND that's all. It seems simple. WDYT?

Why not just take the first only, and reject all following ones until the first succeeds or rejects? That also seems pretty logical to me, though we could improve the error message about why the later calls fail.

Improving error messages would definitely help.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Discussed at issue triage meeting. Consensus is that the first dialog requested is the one that should be shown. This is the current behavior given that showing the dialog consumes the user gesture.