On Thursday, October 3, 2013 at 11:04 PM, Charles McCathie Nevile wrote: > On Thu, 03 Oct 2013 22:50:21 +0100, Vincent Scheib <sch...@google.com > (mailto:sch...@google.com)> > 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 (public-test-in...@w3.org), 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
