Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify wording on object equality #241

Open
RReverser opened this issue Oct 17, 2023 · 2 comments
Open

Clarify wording on object equality #241

RReverser opened this issue Oct 17, 2023 · 2 comments

Comments

@RReverser
Copy link
Contributor

Is USBDevice equality guaranteed between different calls to getDevices() or requestDevice(), assuming that given device wasn't disconnected in between?

I assume it has to be - and, indeed, in the current implementation it seems so - otherwise things like comparing device from ondisconnect event with the stored instance also wouldn't work, but the spec only uses loose wording like

Add the USBDevice object representing device to devices.

which could also mean that implementation might be returning a collection of new USBDevices for each getDevices() call.

If it is indeed guaranteed, it should be reflected in the spec.

@nondebug
Copy link
Collaborator

Yes, object equality is guaranteed.

I think this is already guaranteed by the spec, but it could be made more explicit. The spec describes how to create "a new USBDevice object representing a connected USB device". These steps are only run "When a USB device is connected and detected" so it should only run once per connected device.

We use the same "the USBDevice object representing device" language whenever we need to return a USBDevice object (getDevices, requestDevice, connect/disconnect events). The spec doesn't say "new" here so I read it as referring to the object that was previously created when the device was first detected.

For WebHID I defined an internal slot navigator.hid.[[devices]] to hold HIDDevice objects for available HID interfaces. Perhaps we can adopt similar language to make it clearer how the USBDevice objects for available devices are created and stored.

@RReverser
Copy link
Contributor Author

RReverser commented Oct 17, 2023

The spec doesn't say "new" here so I read it as referring to the object that was previously created when the device was first detected.

Yeah it doesn't say "new" but between

The UA MAY cache the result of the first enumeration it performs

and

Add the USBDevice object representing device to devices.

it's easy to misread this combination as if enumerated devices might be not cached and, correspondingly, that devices will be discovered anew and, correspondingly, wrapped into new USBDevice whenever you call getDevices.

I'm glad to hear it's guaranteed as this will simplify some code I have, just saying the spec wording could be more explicit here in that case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants