How to properly abort a `device.gatt.connect()` attempt

[mgibbs189]

Hello,

Could someone please describe the "correct" way to handle a failed reconnection attempt?

When gattserverdisconnected fires, I want to try reconnecting for up to 30 seconds, then abort. This seems like a common use-case.

let device, server;
let timeout;

let timeoutPromise = new Promise((_, reject) => {
    timeout = setTimeout(() => reject(new Error('Connection timeout')), 30000);
});

try {
    server = await Promise.race([device.gatt.connect(), timeoutPromise]);
    // successfully reconnected, do other stuff
}
catch(err) {
    // failed to reconnect, how to abort connect()?
    // this often causes `navigator.bluetooth.requestDevice()` to stop responding, perhaps
    // because the browser is still actively trying to connect?
}
finally {
    clearTimeout(timeout);
}

It'd be super helpful if someone could clarify what happens with connect behind the scenes...

• Is there actually a way to abort device.gatt.connect()?
• Is there any browser-level timeout? Or, will a connect() run indefinitely (i.e. the lifetime of the pageload)?
• What does gatt.device.disconnect() do, when a device is disconnected/dropout, or when a connect() is running for that device?

Thanks

[dlech]

See #152

[mgibbs189]

Thanks @dlech -- yikes, it's almost a decade old.

What do you think are the chances we can get some traction on this issue? I'm not super familiar with Chromium's dev cycle.

This seems like a pretty fundamental issue 😬

[reillyeon]

I believe the Chrome team is tracking this as a higher-priority issue when combined with persistent permissions as it becomes more likely a site will try to connect to a device that is not in range.

@nondebug

[mgibbs189]

@reillyeon You're on the Chromium team, right? Mind if I ask your exact involvement?

I'd love to see this one get resolved, and will do everything in my power to help make that happen. It's such a critical feature.

What does the Chromium team need from me and/or the community in order to get the ball rolling on this one?

[reillyeon]

I am on the Chrome team but am not as involved with Web Bluetooth as I have been in the past.

As much as it feels like shouting into the void please keep posting about the importance of fixing issues like this. It helps if you provide information about the application you are building and the company you work for so that we get a sense of the impact of missing features like this so we can prioritize.

If you're comfortable with C++ of course patches are welcome but our team will try to get to things like this. There are just so many features and so little time.

[nondebug]

The Chromium bug filed for this issue (https://crbug.com/40502943) is marked as a blocker for crbug/40632400: Implement persistent Web Bluetooth permissions which is on our roadmap for 2025.

As @reillyeon said, providing information about how your company will use this feature helps us justify this work against other high-priority work.

[mgibbs189]

@nondebug @reillyeon please see this post for more background: https://issues.chromium.org/issues/40502943#comment33

Would it be a possibility for Google to offer some sort of sponsorship or grant to fast-track development? I was contacted by a dev agency willing and able to contribute, but I don't personally have the funding to sponsor it.

[g-ortuno]

Hi! Trying to understand the feature request here. If I understand correctly, platforms have their own internal timeout for connection attempts, for example Windows will time out after 7 seconds. MacOS is the outlier with not timeout. Is the feature request to be able to abort connections because MacOS has no timeout? Or are there issues on other platforms that make this feature useful there too?

[dlech]

It think the timeout would be sufficient for our use case. (It might be nice if the DOMException in the rejected promise had name of TimeoutError on all platforms in this case)

pybricks/support#911 has a useful test to reproduce the issue (this was on Linux). It can be generalized as:

• Click a UI button that invokes requestDevice() to open the device picker popup.
• Have a device advertise so that it shows up in the list.
• Select the device, but don't click the Pair button yet.
• Turn off the device so that connection is not possible.
• Click the Pair button.
• The promise never resolves, so you have to reload the page.

[g-ortuno]

Looking more into it, this was recently implemented (excluding Windows and Android): https://crrev.com/c/6798921. I just tested it on a M1 Macbook Pro and I can cancel pending connections and connect successfully after.