Add new Dispatching Action "Wheel" #1409

[robert-snakard]

When testing websites a developer may wish to test a WheelEvent. I propose that we add a new "pointerWheel" subtype to the "pointer" action. Then there would be a "pointer wheel" action with arguments "action item" and "action". We could then let "delta_x", "delta_y", and "delta_z" be the results of getting the properties delta_x, delta_y, and delta_z from "action item".

One alternative would be to create a new source type "wheel" alongside "none", "key", and "pointer". The only issue I see with this alternative is "wheel" would only have one subtype, "scroll" (and pause but that's irrelevant). Other than that problem, this seems almost entirely a bikeshed argument. Do we want more source types or more subtypes?

Copied from #1409

---

Preview | Diff

[andreastt]

I see the usefulness in being able to spin the wheel to generate these DOM events.

I only have superficial insights into the how this is supposed to map down to underlying specs, but I see that UI Events does define wheel events, producing WheelEvents. The wording in this patch looks OK to me.

@jgraham wrote most of this, so he might be a better candidate to review how it interacts with those specs.

A few questions:

• Is this implemented anywhere, or is there a strong commitment to implement this feature from vendors?
• Are there WPT tests?

[robert-snakard]

@andreastt

• This is currently not implemented anywhere.
• I will be writing WPT tests for this

Issues resolved by author

[shs96c]

Hi. Just following up on this (eventually --- my apologies for the slow reply) Is there any progress on the tests? This looks like a nice enhancement to the spec, and I think people are interested in implementing it.

[jgraham]

So, this was discussed in the working group. I think we'd like to try a slightly different design that's more like how pointerMove works.

So the idea is that we'd have a scroll action associated with the null input type with a structure like:

{
  x: <number>,
  y: <number>,
  origin: <"absolute"|"relative"|<WebElement>>,
  duration: <number>,
  type: <null|"wheel">
}

So the idea is that you can scroll either to an absolute (x, y) coordinate, by an offset relative to the current scroll position, or to a position relative to a web element. The type attribute specifies the kind of virtual device associated with the scroll; with the default null value it's roughly like using a DOM API, with type of wheel you get whatever events scrolling with a mouse wheel would produce (if that's a thing that makes sense on your platform).

[jgraham]

Oh, and we should support a duration property to lengthen the tick. For ticks of non-zero duration we should divide the action into a series of small changes across the tick just like we do for pointerMove.

[bokand]

with the default null value it's roughly like using a DOM API, with type of wheel you get whatever events scrolling with a mouse wheel would produce (if that's a thing that makes sense on your platform).

Why would the API need to support "none", rather than letting the client use the DOM APIs? The other arguments (e.g. x, y, duration) don't really make sense for a DOM like scroll. If implemented as a wheel-like scroll that doesn't dispatch wheel events, I'd be worried this would introduce behavior that's not shipped in production.

One additional point that I think would be useful to handle is precision. In particular, high-precision touchpads on laptops usually (always?) treat scrolling as though it were coming from a mouse wheel but with per-pixel precision. This is often used as a signal to treat the scroll differently, e.g. disable animating the scroll. It would be useful to have some way of simulating the scroll as coming from this kind of device.

[LanWei22]

Below is our design doc on adding the wheel actions with some mouse wheel tests, please take a look
https://docs.google.com/document/d/1AzPkvexzuUJ1SF-6pZFpnn2lwEYlk3T0e-Wi52UWFZ4/,
thank you.

[bwalderman]

@Summerlw I'm glad to see there's interest in implementing this.

In general I do agree that adding a new device subtype is the right approach over using the null input device. However, I have some concerns about introducing "wheel" as a new device type and having this be the only device type that can perform a "scroll". There are other types of devices that can be used to scroll, such as a laptop trackpad, as @bokand pointed out.

As an alternative, I'd prefer to let any "pointer" device perform "scroll" actions. Implementations could use the "pointerType" property to determine what kind of scroll to simulate. For example, if pointerType=mouse, the implementation can simulate a mouse wheel. if pointerType=touch, then the implementation can simulate a scroll as if the user is moving fingers on a trackpad, etc.

[LanWei22]

If we add an action of "scroll", and pointerType=touch, it does not mean the user is moving fingers on a trackpad, it is actually moving fingers on the touch screen, like a monitor. Trackpad is different from a monitor. Also, the reason we do not add wheel as a action no matter under where is wheel does not do scroll only, it also can zoom. I proposed to add scroll as a source type, which is not a device type. Source types are key, pointer, none right now. For trackpad scroll, we can add a new device type, like the pointer type.

[whimboo]

A wheel action type with a scroll action was actually added a while ago.