I got some concerns here after initial look. It prevents UA to do what it wants in some cases. For example, when an adapter is added, maybe the UA choice would otherwise be keep the previously acquired adapters alive and well. But following this logic would make the UA to fail the device creation.

Editors meeting: had a long conversation about this and we're still thinking on it.

Revised based on discussion in editing meeting.

The general idea looks good but I have a slight concern about the composability of things in asynchronous scenarios. Consider the following code:

let currentDevice = null;

async function asyncReinit() {
    const adapter = await gpu.requestAdapter();
    currentDevice = adapter.requestDevice();
    initWithDevice(device);
}

resetButton.onclick = () => {
     asyncReinit();
     currentDevice.destroy();
}

This code look like it should properly destroy the device and reinitialize it, and that the order of asyncReinit and .destroy() don't matter. But it actually does because of this additional boolean state introduced in this PR. (and the code in the example will fail to create a device).

This might be slightly worse in pages using multiple WebGPU components that don't know about each other. The timing of things could lead to hard to reproduce issues where devices fail creation. This issue isn't a huge blocker but it would be nice to fix it if it's not too hard.

This might be slightly worse in pages using multiple WebGPU components that don't know about each other. The timing of things could lead to hard to reproduce issues where devices fail creation. This issue isn't a huge blocker but it would be nice to fix it if it's not too hard.

FWIW, a previous draft of my rework had a GPUAdapterProvider and put the [[active]] state on that. Each applet on a page would create its own GPUAdapterProvider once at startup (providing its adapter options there) and receive adaptersadded/adapterschanged events on it.

This code look like it should properly destroy the device and reinitialize it, and that the order of asyncReinit and .destroy() don't matter. But it actually does because of this additional boolean state introduced in this PR. (and the code in the example will fail to create a device).

I've fixed the PR so it actually ever sets [[adapters_active]] to true. It occurs during resolution of the requestAdapter result. So this example code should be fine, but it's still possible to have a race if destroy() is called asynchronously in such a way it could occur between the end of requestAdapter and the end of requestDevice.

I think the design is actually reasonably robust to this. If this does happen flakily, an already-lost device is returned, and the application should recover from that in the normal way by trying again.

Ok, I think that's a little window for conflicts so it's probably fine. You previously had a proposal for making requestDevice into createDevice. I don't know if it is still current but it would fix the last possible flakes if the application creates the device in the promise resolution microtask.

Editors discussed this more, and I think we are going to make requestAdapter(s) return new GPUAdapter object(s) every time, as this is the most forward-compatible. Instead of [[adapters_active]] we can have existing GPUAdapter objects become permanently invalidated. It also reduces the risk of multiple apps on a page stumbling over each other (e.g. overwriting each other's expando properties).

In the future we can consider allowing requestAdapter(s) to return the same GPUAdapter object(s) multiple times, which would allow applications to do equality comparisons or hang expando properties off of them. This would be a nearly-non-breaking change, less risky than going the other way. Alternatively we can start guaranteeing that the name field will be a unique identifier so apps can compare that instead (maintaining the isolation between apps on a page).