Thanks Tobie.
Vincent - I recommend you forward your original message directly to
[email protected] (FYI, the Web-driver folks also use W3C's
#testing channel).
I don't think any of WebApps' tests currently use Web-driver so there
could be a bit of learning curve here but it's likely other specs will
have similar requirements (f.ex. gamepad, screen orientation, fullscreen?) .
-AB
On 10/3/13 9:18 PM, ext Tobie Langel wrote:
On Thursday, October 3, 2013 at 11:04 PM, Charles McCathie Nevile wrote:
On Thu, 03 Oct 2013 22:50:21 +0100, Vincent Scheib <[email protected]
(mailto:[email protected])>
wrote:
Pointer lock is tricky to automate tests for. Consider some examples:
- Upon lock, no pointer should be visible.
That might be tested using a reftest[1].
- A user gesture is required to lock when not in fullscreen.
That might be tested using a WebDriver test (we haven't agreed on a way to
write or run those yet).
- Transitioning to fullscreen and pointer lock then exiting fullscreen
should maintain pointer lock. (User gesture required to enter fullscreen)
This might also be feasible using WebDriver.
- While locked, moving the mouse indefinitely in any direction must
continue to provide non zero movementX/Y values.
That could be automated using WebDriver.
I'm considering starting some pointer lock tests with testharness.js. The
only solution I see is to provide instructions in many tests
for manual actions and observations.
If there's interest on your side to explore the WebDriver-based option, I'm
happy to start a discussion on how those tests should be written in the
relevant channel ([email protected]), but that really depends on what
your main goal with this effort is (move the spec along the REC track, or
improve interop) and what your timeline's like. If you want to ship the spec
quickly, going the manual route with testharness.js is probably your best
option. You'll always be able to revisit later (you could even do both in
parallel).
--tobie
---
[1]: http://testthewebforward.org/docs/reftests.html
