Shall we create a dblclick event when the cursor have moved to a different location between two clicks?

[sefeng211]

Consider this wpt test_driver usage
await new test_driver.Actions().pointerDown().pointerMove(300, 300).pointerUp().pointerDown().pointerUp().send();,
this makes two clicks but no dblclick in Chrome and and two clicks + one dblclick in Firefox.

Both behaviours make sense in some ways, so we should clarify which behaviour we want in spec.

cc @smaug----

[garykac]

In my (in progress) rewrite of event handling, whether or not something is a double-click is determined by the underlying native OS.

This is required because the OS will typically have accessibility features that allow the user to specify the click-delay for 2 clicks to qualify as a double-click. And the browser should respect that.

To simulate this properly in a test, I think you'd need to inject proper native mouse events and have the OS generate the extra dbl-click event for the browser.

[sefeng211]

@garykac Just make sure I understand. It sounds like we would still have this inconsistent behaviour after your rewrite of event handling, once it fully relies on the OS, due to the test framework simulates the pointer behaviour instead of native mouse events.

Do you think clarifying the expected behaviour in the spec is a bad idea? I can see the argument because this is going to be a test framework only thing.

[garykac]

With the rewrite, the behavior would be specified because it would say something like: generate a dblclick event only if the native OS tells you to.

WRT the sequence of events given above:
(a) It wouldn't really be testing the spec because it wouldn't be injecting native mouse move/click events
(b) However, since it injects events into the middle of the algorithm, the rest of the algorithm should match between UAs

I'm curious about why Firefox apparently synthesizes dblclick events here when they were not provided by the OS. If that is a useful feature, then it should be spec'ed and implemented in all user agents. But as noted above, there are accessibility issues to address as part of that.

[sefeng211]

Thanks! The dispatched dblclick is actually from firefox's webdriver implementation and we think this is a bug. Here's the tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1681076

So yeah, rewrite the spec to rely on native OS sounds perfect.

I am going to close this issue since I think this is a firefox bug.

[garykac]

Great! Thanks for investigating this and following up.