Pointer lock is tricky to automate tests for. Consider some examples:
- Upon lock, no pointer should be visible.
- A user gesture is required to lock when not in fullscreen.
- Transitioning to fullscreen and pointer lock then exiting fullscreen
should maintain pointer lock. (User gesture required t
On Thu, 03 Oct 2013 22:50:21 +0100, Vincent Scheib
wrote:
Pointer lock is tricky to automate tests for. Consider some examples:
- Upon lock, no pointer should be visible.
- A user gesture is required to lock when not in fullscreen.
- Transitioning to fullscreen and pointer lock then exiting f
On Thursday, October 3, 2013 at 11:04 PM, Charles McCathie Nevile wrote:
> On Thu, 03 Oct 2013 22:50:21 +0100, Vincent Scheib (mailto:sch...@google.com)>
> wrote:
> > Pointer lock is tricky to automate tests for. Consider some examples:
> > - Upon lock, no pointer should be visible.
>
That migh
Thanks Tobie.
Vincent - I recommend you forward your original message directly to
public-test-in...@w3.org (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
[BCC webapps, +test-infra]
Dear test infra, I've a pointer lock spec [1] which will be easiest to test
with automation such as WebDriver. I haven't used WebDriver, nor
testharness.js tests yet. As Tobie suggests below, I'd like to explore a
WebDriver option in the w3 context. This is a long term g