Re: [w3c/gamepad] Interop 2025 investigation effort - Gamepad API testing (Issue #219)

nondebug left a comment (w3c/gamepad#219)

> Would you consider a similar approach to the [WebXR Test API](https://immersive-web.github.io/webxr-test-api/)?

@msub2 I'm not sure how much we can reuse from the WebXR test API since it's not a WebDriver API. Some areas where I think this API should not follow WebXR:

* WebXR sets each button input separately ([updateButtonState](https://immersive-web.github.io/webxr-test-api/#dom-fakexrinputcontroller-updatebuttonstate)) which doesn't match how gamepad inputs are typically read by the browser. A typical gamepad sends all button and axis inputs as a single packet, and the browser updates all input fields at the same time. If we set each input separately, we lose the ability to simulate multiple inputs changing in the same input frame. This doesn't matter too much right now but might become more important if we extend the API to support input events.
* We should try to use the existing WebDriver BiDi API for simulating inputs: [input.performActions](https://w3c.github.io/webdriver-bidi/#command-input-performActions). We can define Gamepad API specific actions for connecting/disconnecting gamepads and updating input state.

> There is an example of specifying device simulations as a WebDriver BiDi extension

Let's figure out if we need a FakeGamepad object. If we don't need it then it's simpler to define actions for gamepad connections/disconnections instead of a simulateConnectedGamepad API.

I think it's likely that we do need a FakeGamepad object since there are cases where the gamepad is connected but not visible to the site (for instance, if a gamepad user gesture has not been received).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/219#issuecomment-2715391344
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/issues/219/2715391344@github.com>