[w3c/gamepad] GamepadHapticActuator promises race conditions (Issue #200)

There appear to be a couple of issues with the interactions between `playEffect()` and `reset()` of the [`GamepadHapticActuator Interface `](https://w3c.github.io/gamepad/#dom-gamepadhapticactuator):

1. Parallel steps manipulate or read the `[[playingEffectPromise]]` internal slot: step 8.2 of `playEffect()`, and step 4.3.1 of `reset()`. Even though the slots are internal, they should only be read from or written to from a task, not from parallel steps. 
2. It is not clear how `playEffect()` handles multiple calls: step 4 checks if there is an existing promise, but later step 6 seems to immediately set a new one. By the time of step 8.2.2(resolving the promise) the promise could be already a new one from a later call to `playEffect()`. I think it should, like `reset()`, store the promise in a variable, and then when the task runs: check for equality of promises(perhaps using an explicit generation counter of some kind), and either resolve the promise with `preempted` or `completed`. 
3. `reset()` step 4.4. resolves a promise right on the parallel steps: it should do this inside a task.
4.  `reset()` step 4.4. if conditional on step 4, so it appears that calling `reset()` when there is not running effect will never resolve the returned promise. Perhaps it should be rejected immediately in that case? 

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

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