search

immersive-web / webxr

Repository for the WebXR Device API Specification.
https://immersive-web.github.io/webxr/
Other
3k stars 386 forks source link

Use of FrozenArray<>s in dictionaries is unnecessary and bad #1368

Closed domenic closed 7 months ago

domenic commented 7 months ago

The spec has one "init" dictionary which accepts FrozenArray<XRInputSource>.

It's not clear what was intended here. But per the Web IDL spec, almost the exact same set of values are accepted compared to accepting the more conventional sequence<XRInputSource>.

(The difference is that certain proxies for arrays, which define throwing getOwnPropertyDescriptor() traps, would be rejected, because in theory the implementation is supposed to freeze the incoming array.)

We'd like to prohibit the usage of FrozenArray<T> as a dictionary member in Web IDL, per https://github.com/whatwg/webidl/issues/1399. It would be lovely if you could move to using sequence<>s.

Maksims commented 7 months ago

Is it frozen to avoid any modifications of it by the application? Which allows implementers to provide the same array and know that it only gets modified by them. Which eliminates a need to return a new array each time, which is beneficial for GC as many of these arrays can be referenced many-many times each frame.

petervanderbeken commented 7 months ago

The attributes can still return a FrozenArray<XRInputSource>.

But the array passed in the dictionary is not frozen. First a sequence<XRInputSource> is created, and then a new array is created from that but is then frozen. Using a sequence<XRInputSource> would work mostly the same. The constructor can then still create a frozen array from that if that's needed.

Note that as currently written the spec doesn't really work, it also still needs to create a frozen array, since the attributes are defined as being a list, which does not magically convert to a FrozenArray<XRInputSource>.

AdaRoseCannon commented 7 months ago

/agenda Bringing it up at the next teleconference call.

toji commented 7 months ago

This appears to be a simple copy-paste error, where the attributes from the event were brought over to the associated init dictionary too literally. There's no reason I'm aware of why this needs to be a FrozenArray on the dictionary, though as @petervanderbeken points out it can and should continue to be a FrozenArray on the event itself.

toji commented 7 months ago

Put up a pull request to fix this. We can bring it up at the next call, but I think it'll be more of an advisory "Hey, this is a change that's gonna land" rather than something anyone will actually be concerned about.

domenic commented 5 months ago

I'm not sure who here is involved in the WebXR hit testing spec, but I have two similar issues over there which could use some attention, if there is any overlap: https://github.com/immersive-web/hit-test/issues/116 https://github.com/immersive-web/hit-test/issues/117

toji commented 5 months ago

It still falls broadly under this group. I can fix them.