A flag is needed to suppress sending the action to the browser and only to update state of the pointer

[NavidZ]

In chapter 17. Actions, section 17.3 Processing Actions Requests:

When required to process a pointer up or pointer down action with arguments action item, and action, a remote end must run the following steps:

Let button be the result of getting the property button from action item.
If button is not an Integer greater than or equal to 0 return error with error code invalid argument.
Set the button property of action to button.
Return success with data null.

For some of the pointertypes that don't support hover (like current touch screen devices and some styluses) the first action that they inject is indeed a pointerdown and no pointermove before them. So similar to the pointermove we need x,y, and origin for pointerdown as well.

[NavidZ]

FYI @Summerlw

@jgraham we are about to change the testdriver-action.js builder api in wpt to accommodate for this to be able to automate touch event tests.

[jgraham]

I think the intent here was that you do a pointerMove and for devices that don't generate events for a pointer that isn't depressed you just get no events.

[NavidZ]

In principle I agree with you. But I bet this will be confusing for the users of the API. For example whether a pen supports hover or not is a characteristics of the hardware and the platform. External Wacom pens do support hover and Chrome book stylus does not expose the hover events to the applications at all.

Also if were to match the underlying platforms we need to allow the coordinates in pointerdown action as well. Particularly we can get a down event with coordinates from the underlying platforms directly looking at their APIs. Also I guess some of the accessibility tools that intercept the input might down directly as a result of an action instead of a move and then down.

So if we let the driver inject such a down action (with coordinates) in general even for devices like mouse that do support hover it is more close to the real world events.

[jgraham]

It explictly breaks the model for mice to be able to pointerDown at a different cocordinate to the current pointer location, whereas for non for other input types, it's more a question of style I think; the model of move-and-down where the move only affects driver state when the pointer's in a raised state can be exposed to the application as a single down event with coordinates.

I'm not sure what the right model for hover is. How is that exposed in web apis?

[NavidZ]

I'm not sure what the right model for hover is. How is that exposed in web apis?

It is kind of exposed in https://wicg.github.io/InputDeviceCapabilities/ as pointerMovementScrolls but not yet fully adopted. Not event Chrome implemented it yet. I don't have much to add to the exposure of this property to the web. We can certainly assume that it is not exposed at this time to the web directly. They might somehow guess it based on the pointer types and whatnot but that almost certainly breaks for pen pointer types.

It explictly breaks the model for mice to be able to pointerDown at a different cocordinate to the current pointer location, whereas for non for other input types, it's more a question of style I think; the model of move-and-down where the move only affects driver state when the pointer's in a raised state can be exposed to the application as a single down event with coordinates.

I'd like to discuss about this one a little more. There is no specification defined such an ordering. A web app should handle the down event without any preceding move event at anytime. There is no guarantee that they always a get a move and then down and they very well might get that in lots of situations in current Chrome implementation. With the current model of always asking the pointermove command before down in the driver api we are making it impossible to test down only event scenario for mouse. Don't we?

[jgraham]

Like moving the pointer outside the window, then back in, or having the window move under the pointer? I see how that could generate events that can't be modelled in WebDriver. So I guess I can see that some way to perform "invisible" moves may be required. I would be inclined to model that as a pointerMove with a flag to suppress events, because I think that makes the API more obvious (and flexible; if you have a sequence pointer down, viewport moves, pointer up, then that requires both pointerUp and pointerDown can take x y coordinates in your proposal whereas in my proposal it is supported naturally).

[NavidZ]

I'd be fine with that too. Now that I'm thinking I guess we might need that flag for down and up events as well. Like user presses down left button outside the browser (hence the buttons will become 1) and when the first event browser sees is a pointermove as a result of a mouse move with buttons=1 (i.e. left button is depressed) and button=-1 (no button change caused this very move event). WDYT?

[jgraham]

Theoretically that seems fine. I don't know how hard it would be to implement :)