"completed" promise can be wrong one if called multiple time: a second call will set the promise to null and queue a "preempted" task, but then immediately set the promise to a new one. The "completed" task for the first call would then run and resolve the second promise. Solution: like in reset, check for promise equality.
8.2 checks for promise in parallel steps: unnecessary and reading the internal slot should be done in a task.
reset:
step 4.4. resolves a promise right on the parallel steps: it should do this inside a task. Also, it is conditional on step 4, so it appears that calling reset() when there is no running effect will never resolve the returned promise. Perhaps it should be rejected immediately in that case?
step 4.3.1 reads slot from parallel step: move it below to inside the task.
Also it's not clear to me how to compute "are still the same" for two promises, so the spec could be explicit about it and add a generational counter internal slot, that would be passed around to parallel steps by cloning it to a variable and back to queued tasks for comparison with the internal slot.
There appear to be a couple of issues with the steps of
playEffect()andreset()of theGamepadHapticActuator Interface:playEffect:reset, check for promise equality.reset:reset()when there is no running effect will never resolve the returned promise. Perhaps it should be rejected immediately in that case?Also it's not clear to me how to compute "are still the same" for two promises, so the spec could be explicit about it and add a generational counter internal slot, that would be passed around to parallel steps by cloning it to a variable and back to queued tasks for comparison with the internal slot.