- From: <bugzilla@jessica.w3.org>
- Date: Thu, 18 Dec 2014 15:50:16 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21434 --- Comment #5 from Ted Mielczarek [:ted] <ted@mielczarek.org> --- (In reply to Philip Jägenstedt from comment #4) > Live Array-like objects like NodeList are more work to implement and test, > we should avoid making more of them. Yeah, I don't think anyone is arguing for that, thankfully. > That navigator.getGamepads()[0] === navigator.getGamepads()[0] should always > hold true seems like a given, otherwise you'll necessarily have multiple > Gamepad objects representing the same underlying hardware, and the mess of > Unless the idea is that a Gamepad object is a snapshot > and you have to call getGamepads() every time you want to check for changes? > Easy to implement, but a bit odd... This is the entire crux of this bug: currently the Gamepad objects in Firefox always represent the most-recent-available state of the controller, whereas in Chrome and IE they represent a snapshot of the state as of the time you called navigator.getGamepads(). There was a long thread about this on public-webapps earlier this year: http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0238.html It didn't really reach any strong conclusions, there are good arguments to be made both ways. One compelling argument that was made is that if we do spec some sort of data change events in the future we will want snapshots for that: http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0257.html There's also a pretty good argument (that didn't come up on-list) that having snapshots makes it easier to compare gamepad state in the polling model, since you can hang on to the previous snapshot and compare vs. the next snapshot (using .timestamp, for one, and checking whether button states match etc). -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 18 December 2014 15:50:21 UTC