When the low level actions was written when Chrome had said that they were
not going to Pointer Events so they are in need of rewrite. It also needs a
rewrite for other reasons so let me know what changes you would like to
have and I will try to accomodate them. I will be tackling this soon.
David
On 17 June 2015 at 18:08, Jacob Rossi <Jacob.Rossi@microsoft.com> wrote:
> On Tue, Jun 16, 2015 at 10:10 AM, James Graham <james@hoppipolla.co.uk>
> wrote:
> >
> > On 16/06/15 17:46, Rick Byers wrote:
> >>
> >> Thanks for kicking this off Doug,
> >>
> >> To me the main issue to discuss is whether / how the WebDriver API
> >> should be extended to support rich input support (it's really too
> >> limited at the moment to be that useful for scenarios like pointer
> events).
> >>
> >> I've started a blink-specific thread to discuss using WebDriver in our
> >> tests here
> >> <
> https://groups.google.com/a/chromium.org/forum/#%21topic/blink-dev/0lXHWPF4lD4
> >.
> >
> >
> > It would be nice if we could avoid fragmenting the discussion so early.
> >
> > So:
> >
> > * Using WebDriver for doing automated testing of (the content area of)
> browsers has always been part of the plan going forward.
> >
> > * How to do this in a really nice way, browser-independent, isn't clear.
> All the existing W3C test infrastructure is written in python, so adding a
> node dependency would be unwelcome. Making authors write tests spanning
> multiple files is also additional overhead compared to the state of the art
> in browser-internal test frameworks.
> >The best idea so far is to attempt an in-browser webdriver implementation
> that will allow calling out (via XHR or WS, or something) to an external
> server implementing a WebDriver client, that will inject the WebDriver
> commands and return the results. I'm sure this can work, but I am a little
> scared of the complexity.
>
> This is more or less how some of our internal tests work today (though we
> have to use a different component than WebDriver since it doesn't yet
> satisfy all our input needs). So I wouldn't be too afraid. :-)
>
> > * The actions API is being specified to provide lower-level input
> support. You can see this in the current spec, but the actual text needs a
> bunch of work (more than any other part of the spec).
>
> Here's the deep link for those that haven't seen it:
> https://w3c.github.io/webdriver/webdriver-spec.html#low-level-actions
>
> For the Pointer Events test suite, the pointerMove/Down/Up APIs would need
> to be extended with additional parameters to be able to control device
> properties like pressure, tilt, additional buttons, etc.
>