I do not think the scenarios under "system's power configuration has changed" should always trigger WebGPU context lost unless the browser specifically wants content to be moved from the high power adapter to the low power adapter.

If the WebGPU content is on a low power adapter, it should remain "current" regardless of the laptop being unplugged or power settings changing.

Perhaps change the wording from "should" to "could" here.

It doesn't trigger device loss, it just puts the adapter into a state where it cannot vend new devices.

Earlier in the PR, it says:

Any time the user agent needs to revoke access to a device, it calls [=lose the device=]

The PR doesn't go into detail about when "invalidation" is different than "revoking access" so I thought (incorrectly) that those were the same thing. This could use more clarification.

However, unless I am misunderstanding the proposed wording, there's still more information disclosure happening than necessary. If the system's power configuration has changed and an adapter that used to be on the old list is also on the new list, we shouldn't set its "current" flag to false. Right?

No GPUAdapter object will ever be returned more than once. Every time you call requestAdapters you get new GPUAdapter objects even if they refer to the same underlying hardware.

The PR doesn't go into detail about when "invalidation" is different than "revoking access" so I thought (incorrectly) that those were the same thing. This could use more clarification.

ACK Renamed to clarify

OK. Then by the same token, if the system's power configuration has changed and an OS adapter that used to be on the old list is also on the new list, then I think all of the WebGPU adapter instances corresponding to the OS adapter should continue to handle out devices. Do you agree?

What benefit would there be to allowing applications to continue vending devices from those adapters?

Because those adapters are still perfectly fine to use.

If I unplug my hybrid laptop and WebGPU is running perfectly fine on the battery saving adapter, the web developer should be none-the-wiser to my actions. With your PR, the web developer can detect what I've done by noticing that the WebGPU adapter object for the low power adapter no longer gives out WebGPU devices. Giving this information to WebGPU developers does not help them write better WebGPU programs so we shouldn't give it out.

Now if I unplug my hybrid laptop and WebGPU is running on the power consuming adapter, I'm more comfortable having the power consuming WebGPU adapter object stop giving out WebGPU devices. Here, there's a user benefit to giving developers this information, so it's worth doing.

I want to resolve that by marking adapters stale more often, not less.

I used to have that written into the spec but it didn't make it into this revision of the PR, something like:

mark adapters stale may be scheduled at any time, and user agents may choose to do this often (e.g. on a timer), even when there has been no system state change. This has no effect on well-formed applications and makes developers aware that calling requestAdapters again is always necessary if a new device is desired.

Added to the spec

I think having the browser randomly mark adapters stale for no use benefit seems overkill.

If we're going to have a "current" flag, I think it's sufficient for the spec to simply say: "Similar to context-lost, developers should be prepared to encounter adapters where the current flag has becomes false during the course of the WebGPU program. Examples of cases where the current flag could becomes false include: power state changes, and physical adapters becoming added/removed."

Taking a step back, when will it be the case that an adapter becomes non-current but does NOT become lost? If a developer discovers the adapter they're currently using is non-current but is happily accepting draw commands, should they take that as a hint to move their operation somewhere else? Is it an omen of possible calamity ahead?

I think having the browser randomly mark adapters stale for no use benefit seems overkill.

There is a benefit though: it makes it much harder to accidentally write applications which fail in rarer situations like system setting changes or eGPU usage. We can't rely on people to read every piece of documentation thoroughly.

Taking a step back, when will it be the case that an adapter becomes non-current but does NOT become lost? If a developer discovers the adapter they're currently using is non-current but [a device on the adapter] is happily accepting draw commands, should they take that as a hint to move their operation somewhere else? Is it an omen of possible calamity ahead?

(Added bracketed part just to make sure I am understanding correctly.)
In my proposal it could mean nothing or it could mean that the UA might decide to lose the device later if the device lives too long and the UA wants to allow the discrete GPU to get powered down. It's intentional that no conclusive information is conveyed. If we want to give apps advance warning of a device being lost, it should be done deliberately, as an event, IMO.