Is this on Windows?

The Windows platform HID API enumerates each top-level HID collection as a separate device. In Chrome 88 and earlier, WebHID would enumerate these as separate HIDDevice objects but in Chrome 89 and later it exposes a single HIDDevice object for all collections that are part of the same HID interface.

When Chrome performs its initial device enumeration, it should be able to find all collections from every connected HID device. However, when devices are hotplugged it's possible for some of the HID collections to be enumerated earlier than others. Ideally Chrome should determine how many HID collections are expected and delay firing 'connect' events until all collections have been enumerated. This information isn't available on Windows, so Chrome fires 'connect' when the first collection is enumerated and updates the collection info (without firing an event) when other collections are found.

It sounds like it may be useful to add a 'devicechange' event that would fire on collection info changes.

Spot on Matt, it is windows and your solution sounds great...

On Windows we can register for notification on each of the top level HID collections it exposes and also on a HID class device. Applications will get device removal notification for all the HID collections as well as a final notification for the HID device itself. Since Chrome now exposes a single HID object I think it makes sense to just have one device added notification when the device is fully enumerated and a single device removal when it is unplugged.

when the device is fully enumerated

If it's possible to know when all exposed HID collections are enumerated then I agree, that would be preferred over modifying the API to add a devicechange event. The current Chromium implementation works the way it does because I couldn't find a way to detect the "fully enumerated" state. Do you know of anything that would help detect when a device is fully enumerated?

I think it's meant to be impossible. Windows can't guarantee that it will enumerate all of the collections described in the report descriptor because some of them might be protected. Applications should not be able to learn about protected collections or reports. WebHID tries to make similar guarantees.

I'm still not really sure what's causing this issue and haven't been able to reproduce it locally. I suspect it has to do with installed vendor drivers introducing some delay in the enumeration step. If it's true that vendor drivers can introduce arbitrarily long delays before collections are enumerated then I don't see any scenario where we can wait for all collections to be enumerated before firing the connect event. The driver might decide not to enumerate the collection at all, causing the whole device to be unusable.

I suspect it's possible for drivers to toggle visibility for individual HID collections which suggests we should fire devicechange when a collection is removed as well as when it's added. I think drivers like HIDGuardian can do this but I haven't tested to see how it interacts with the Chromium implementation.