26181 2014-06-23 18:39:24 +0000 Spec should specify the presentation of the array returned by navigator.getGamepads() w.r.t "holes" 2015-02-09 09:24:22 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Gamepad unspecified All All RESOLVED FIXED P2 normal --- 27549 1 ted ted b.kelemen bajones beidson bugs bzbarsky jrossi mike philipj public-webapps scott.w3bugzilla ted public-webapps-bugzilla oldest_to_newest 108230 0 ted 2014-06-23 18:39:24 +0000 Currently the spec is silent about how the gamepad array should look in the face of removing Gamepads. What Firefox implements (I need to check other browsers) is like: <no gamepads connected> navigator.getGamepads() == [] <connect gamepad 1> navigator.getGamepads() == [Gamepad] <connect gamepad 2> navigator.getGamepads() == [Gamepad, Gamepad] <disconnect gamepad 1> navigator.getGamepads() == [null, Gamepad] The intent is that the array is always at least max(Gamepad.index)+1 length, and entries where there's no longer a Gamepad present are "holes". Firefox uses null for their values, but Chrome and IE use undefined, so the spec should clarify that. (undefined seems sensible) 108232 1 bzbarsky 2014-06-23 18:42:19 +0000 Undefined, or hole? Those are actually observably different in JavaScript: [,1].hasOwnProperty(0) === false vs [undefined,1].hasOwnProperty(0) === true while of course both arrays will return undefined if indexed with [0]. 108233 2 beidson 2014-06-23 18:45:49 +0000 (In reply to Boris Zbarsky from comment #1) > Undefined, or hole? Those are actually observably different in JavaScript: > Since Chrome and IE use undefined, and Firefox uses null, none of them being holes... I would say undefined. 108237 3 ted 2014-06-23 18:59:39 +0000 (In reply to Boris Zbarsky from comment #1) > Undefined, or hole? Those are actually observably different in JavaScript: I had no idea, I was going to ask you that question. Thanks for the info! I think since existing implementations already use undefined that's what we'll spec. 108238 4 bzbarsky 2014-06-23 19:01:09 +0000 You checked that the existing impls actually use undefined, not holes, I assume? 108239 5 ted 2014-06-23 19:12:45 +0000 ...apparently they're holes in IE/Chrome: Chrome: > navigator.getGamepads() GamepadList {0: Gamepad, 1: undefined, 2: Gamepad, 3: undefined, length: 4, item: function} > navigator.getGamepads().hasOwnProperty(1) false > navigator.getGamepads().length 4 IE: > navigator.getGamepads() [ 0: undefined, 1: { }, 2: undefined, 3: undefined, length: 4 ] > navigator.getGamepads().hasOwnProperty(0) false > navigator.getGamepads().length 4 (it turns out Developer consoles just aren't very good at making the distinction here) 108249 6 ted 2014-06-24 00:59:52 +0000 I fleshed out the text around getGamepads: https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html#navigator-interface-extension https://dvcs.w3.org/hg/gamepad/rev/1719d51557f2 I'm not sure if I described the behavior with holes clearly. Boris: is there a more-correct way to state that? 108250 7 bzbarsky 2014-06-24 01:43:38 +0000 It looks OK to me; I'm not aware of a clearer way to define this short of an actual algorithmic description (create an array, set length to N, define property with name K to have the value X, etc). An informative example that actually makes it clear that unset means the property is not present as opposed to set to undefined might be good. 108251 8 beidson 2014-06-24 01:55:19 +0000 > Array indices for which there is no Gamepad with the corresponding index should be unset. I would say: "Array indices for which there is no connected Gamepad with the corresponding index should be undefined." 108252 9 bzbarsky 2014-06-24 02:05:58 +0000 That's too easy to read as "set to the value undefined" as opposed to "not set to anything". 108253 10 beidson 2014-06-24 02:07:29 +0000 Ah, fair enough. Not quite sure of a more clear way to state that part then. I stand by the s/no Gamepad/no connected Gamepad/ change, though. 108270 11 ted 2014-06-24 12:45:35 +0000 Added the "connected" clarification, and added a code sample describing expected behavior: https://dvcs.w3.org/hg/gamepad/rev/7de7f215f35b 108276 12 bugs 2014-06-24 14:19:13 +0000 So Chrome seems to return some sort of GamepadList. What does IE return? What is navigator.getGamepads().__proto__ ? In Gecko that is currently Array. 108281 13 ted 2014-06-24 15:08:34 +0000 IE (dev channel, DC1C0): navigator.getGamepads().__proto__ [ length: 0 ] Chrome (Canary, 38.0.2065.0) : navigator.getGamepads().__proto__ GamepadList {item: function} 108282 14 ted 2014-06-24 15:10:03 +0000 (In reply to Ted Mielczarek [:ted] from comment #13) > IE (dev channel, DC1C0): > navigator.getGamepads().__proto__ > [ > length: 0 > ] This didn't copy/paste what it showed me in the console, it says [object Array]. 116051 15 bugs 2014-12-09 17:17:19 +0000 I wish webidl had some way to say that returned array has holes. Something like sequence<optional Gamepad> getGamepads(); That would be relatively understandable, IMO. 116061 16 ted 2014-12-09 18:07:21 +0000 I'd like to make the spec a bit more sensible here. I'm not particularly tied to a certain behavior here (and I don't think web content is at this point either), but I'd like to hew reasonably closely to what implementations are doing and the direction of the web platform. Apparently ES6 is doing its best to unsupport sparse arrays as a concept, so trying to spec "holes" here is probably not a winning move. Ideally we'd just have a way of spec'ing that the empty slots get undefined. 116096 17 ted 2014-12-10 17:29:28 +0000 I'm fishing for feedback from other implementers to see if anyone has any reasoning for what they've already implemented. 116101 18 scott.w3bugzilla 2014-12-10 18:02:42 +0000 It wasn't particularly intentional in Chrome to my knowledge, it's just whatever the bindings code did with "nothing". It looks like maybe due to https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/modules/gamepad/GamepadList.idl&l=31 . Per comment 16, undefined rather than holey is fine with me. 116102 19 ted 2014-12-10 18:47:17 +0000 The only tricky bit here right now is that WebIDL doesn't have a way to specify "Gamepad or undefined" as a type. We could write "sequence<Gamepad?> getGamepads()" to spec the Firefox behavior of "Gamepad or null", but if we want to use undefined we'll have to have the WebIDL spec invent some way to say that. 116104 20 scott.w3bugzilla 2014-12-10 18:58:30 +0000 Uh, OK. Personally, any of {false, null, undefined, <hole>} seem fine to me. null is fine with me if that's easiest to spec and meets people's expectations. 116105 21 ted 2014-12-10 19:00:13 +0000 Thanks for the feedback. I feel similarly, I just want the spec to say precisely what should happen here so we can make all our implementations agree. 116107 22 scott.w3bugzilla 2014-12-10 19:28:48 +0000 (In reply to Ted Mielczarek [:ted] from comment #21) > Thanks for the feedback. I feel similarly, I just want the spec to say > precisely what should happen here so we can make all our implementations > agree. Yes of course. sequence<Gamepad?> implying null sounds good then, thanks! 116112 23 jrossi 2014-12-10 22:22:30 +0000 Holes make sense to me for keeping track of player/gamepad association. IE uses undefined because that's what our type system happens to produce by default and it matched Chrome. \o/ 116113 24 bzbarsky 2014-12-10 22:26:06 +0000 Except it doesn't match Chrome, because Chrome currently uses holes, not undefined. 116116 25 jrossi 2014-12-10 23:11:26 +0000 The console (unclearly) outputs undefined but is a hole in both IE and Chrome. This code runs identical in IE and Chrome: var g = navigator.getGamepads() g {0: undefined, 1: undefined, 2: undefined, 3: undefined, length: 4, item: function} g.hasOwnProperty(0) false So, unless I'm missing something, the only difference I see here between IE & Chrome is that IE uses an Array and Chrome uses some GamepadList interface (which seems wrong per spec)? 116120 26 bajones 2014-12-11 00:40:31 +0000 If WebIDL doesn't have a way of specifying Gamepad or undefined/hole then I'm all for using a sequence of nullable Gamepads. I'm also not aware of any technical reason for using the GamepadList type, or if there was one I think it's since been negated. We should be able to switch to a proper sequence without any trouble. 116437 27 philipj 2014-12-17 23:04:41 +0000 It would be great to resolve this so that GamepadList can be retired in Blink: https://codereview.chromium.org/808643005/ Doing what the spec currently says with hasOwnPropety(n) being false for the holes seems tricky. Null is easier to implement, but then Array.forEach won't skip those entries, if that was the idea. Off-topically, I'd be interested to know what purpose Gamepad.index and trying to preserve that index in the returned array serves. It seems a bit odd, but I assume it's been discussed to death already. 116480 28 ted 2014-12-18 14:26:28 +0000 (In reply to Philip Jägenstedt from comment #27) > Doing what the spec currently says with hasOwnPropety(n) being false for the > holes seems tricky. Null is easier to implement, but then Array.forEach > won't skip those entries, if that was the idea. I liked the appeal of being able to skip missing entries, but it looks like ES6 is ridding itself of sparse Arrays, so we're swimming upstream by going that way. > Off-topically, I'd be interested to know what purpose Gamepad.index and > trying to preserve that index in the returned array serves. It seems a bit > odd, but I assume it's been discussed to death already. I don't know that it's been discussed much in the spec context, it's pretty simple really. The index can be thought of as the "player number". This is pretty common in console-land where you have a fixed number of controllers, and Gamepad is taking a cue from them (most specifically you can look at Microsoft's XInput: http://msdn.microsoft.com/en-us/library/windows/desktop/ee417001%28v=vs.85%29.aspx#multiple_controllers ). Being able to keep track of which controller is which, especially when you may have multiple devices of the same type connected is pretty important. Having .index correspond to the index in the getGamepads array just seemed sensible at the time, since it allows you to write code like: function onconnected(e) { player.gamepad = e.gamepad.index; } function handleInput() { var gamepad = navigator.getGamepads()[player.gamepad]; } If we compacted the array and got rid of empty entries you'd have to search the array to find the matching device, which seems awkward. 116481 29 ted 2014-12-18 14:34:29 +0000 AFAICT we have two plausible paths forward: 1) Change the spec to match Firefox's implementation: sequence<Gamepad?> getGamepads() This has the benefit of being incredibly easy to spec since the concept is easily expressible in WebIDL. Still need some spec language to indicate that implementations should return null for controllers that have been removed, but I need to write that either way. 2) Spec a GamepadList object with an indexed property getter, and additionally an iterator that returns only entries that are present (the default behavior of ES6 iterators on objects with indexed property getters/length properties is to iterate over 0..length-1). This could capture the existing intended semantics, but it's awfully complicated, doesn't seem to provide a whole lot of benefit, and feels like swimming against the tide of the web platform, since ES6 is trying to deprecate sparse Arrays. I'm leaning towards #1 (and the Blink folks have said they're amenable). Does anyone have a compelling reason to argue for #2? 116484 30 ted 2014-12-18 14:46:52 +0000 For #2, WebIDL has recently grown a maplike declaration that we could use: http://heycam.github.io/webidl/#dfn-maplike-declaration Presumably the resulting spec would look something like: partial interface Navigator { GamepadList getGamepads(); }; interface GamepadList { readonly maplike<unsigned long, Gamepad>; }; This doesn't seem overly terrible, but it does add a fair bit of implementation complexity just to avoid exposing a value for disconnected controllers. In reality, most of the usage examples I've seen (and written) have looked like: var gamepads = navigator.getGamepads(); for (var i = 0; i < gamepads.length; i++) { if (gamepads[i]) { ... } } which works either way. If we implemented #2 then you could eventually write: for (var gamepad of navigator.getGamepads()) { ... } which is certainly appealing. 116487 31 ted 2014-12-18 14:55:48 +0000 Actually, no, since Map semantics don't match Array semantics, and existing content is relying on that (indexed getter, .length property). We could define this using an iterator but it'd get a bit torturous. Jacob: do you have any objections to approach #1? I'm sorry that the spec left this undefined. 116488 32 philipj 2014-12-18 14:59:31 +0000 (In reply to Ted Mielczarek [:ted] from comment #28) > > Off-topically, I'd be interested to know what purpose Gamepad.index and > > trying to preserve that index in the returned array serves. It seems a bit > > odd, but I assume it's been discussed to death already. > > I don't know that it's been discussed much in the spec context, it's pretty > simple really. The index can be thought of as the "player number". This is > pretty common in console-land where you have a fixed number of controllers, > and Gamepad is taking a cue from them (most specifically you can look at > Microsoft's XInput: > http://msdn.microsoft.com/en-us/library/windows/desktop/ee417001%28v=vs. > 85%29.aspx#multiple_controllers ). Being able to keep track of which > controller is which, especially when you may have multiple devices of the > same type connected is pretty important. Having .index correspond to the > index in the getGamepads array just seemed sensible at the time, since it > allows you to write code like: > > function onconnected(e) { > player.gamepad = e.gamepad.index; > } > > function handleInput() { > var gamepad = navigator.getGamepads()[player.gamepad]; > } > > If we compacted the array and got rid of empty entries you'd have to search > the array to find the matching device, which seems awkward. Why not: function onconnected(e) { player.gamepad = e.gamepad; } And then just use that until the gamepaddisconnected fires or player.gamepad.connected is false? Getting the gamepad via getGamepads() on each input event or animation frame will generate a lot of garbage since a new Array is returned each time. The XInputGetState API seems to need an index because there's no equivalent to Gamepad objects to hold on to. 116489 33 philipj 2014-12-18 15:00:28 +0000 Of the two options in comment #29, I think the first (Gamepad?[]) is better. 116490 34 ted 2014-12-18 15:06:14 +0000 (In reply to Philip Jägenstedt from comment #32) > Why not: > > function onconnected(e) { > player.gamepad = e.gamepad; > } > > And then just use that until the gamepaddisconnected fires or > player.gamepad.connected is false? Getting the gamepad via getGamepads() on > each input event or animation frame will generate a lot of garbage since a > new Array is returned each time. Congratulations, you found the other big spec bug I need to fix: bug 21434. 117427 35 ted 2015-01-22 14:17:42 +0000 I changed the spec to use sequence<Gamepad?>: https://dvcs.w3.org/hg/gamepad/rev/105439653c33 So implementations should simply use null as the value for disconnected controllers. I'll write a test for this behavior for w3c-test.org. 117760 36 philipj 2015-02-09 09:24:22 +0000 Thanks Ted, did you get around to that web-platform-tests thing?