[Bug 17309] It is not defined what the value of Gamepad.index should be after disconnecting the gamepad

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17309

--- Comment #10 from Ted Mielczarek [:ted] <ted@mielczarek.org> ---
(In reply to comment #8)
> The important part here is that unplugging #0 doesn't change the index on #1
> when 1 continues to be connected.
> 
> When 0 is reinserted, it should just find the first empty slot, meaning that
> if you had 0,1,2 plugged in, unplugged 0 and 1 and then replugged 1 first,
> it'd be OK for that to become 0 (rather than resuming being 1). If there's
> some reason for it to stay 1, that's OK too (e.g. the Xbox 360 indicator
> thingy has the user still assigned as player 1)

Should we loosen up the spec language then? Something like "If a gamepad is
disconnected, previously assigned indices MUST NOT be reassigned to gamepads
that continue to be connected. However, if a gamepad is disconnected, and
subsequently the same or a different gamepad is then connected, index entries
MAY be reused. It is RECOMMENDED that when the same gamepad is disconnected and
subsequently reconnected that the index value be reused."

(In reply to comment #9)
> Hmm, good question. When there's no devices at all, I'm just returning
> undefined which made the most sense at the time. Creating disconnected
> objects for indices to infinity seems a bit strange.

Sure, that seems sensible, I wasn't proposing having mock objects for all
indices. I simply meant "for an index that used to contain a gamepad object
that is now disconnected". Should we return undefined after it's disconnected,
or should we return the (now-useless) gamepad object?

> Stepping back a bit... In the polling model, I'd honestly been thinking of
> them as "values", not references to be held on to. So, the model was more
> that you'd get data via navigator.getGamepads()[N], consume it, and then do
> the same next time you wanted refreshed data. In that model, there wasn't
> even a connected attribute required because you either got data or undefined
> in the array. I'm not sure if that model helps though, given the other
> approach of onconnected events and hanging on to the gamepad objects
> indefinitely.

I don't think this is going to fly, because content can stash these objects in
arbitrary slots, and will probably expect things to work. I can imagine someone
doing something like:
function Player() {} var p = Player(); p.input = navigator.getGamepads()[0];
// ... poll p.input ...

I can also imagine scenarios where someone has implemented a mock Gamepad
object (say to abstract away keyboard vs. gamepad input).

(Also note that the "grab the object from the onconnected event" is mostly just
a hackaround for my implementation lacking navigator.getGamepads.)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 22 March 2013 17:32:41 UTC