Re: Automating W3C Test Execution with WebDriver for Pointer Events

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.


On 17 June 2015 at 18:08, Jacob Rossi <> wrote:

> On Tue, Jun 16, 2015 at 10:10 AM, James Graham <>
> 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
> >> <
> >.
> >
> >
> > 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:
> 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.

Received on Wednesday, 17 June 2015 23:51:39 UTC