This WPT test_driver usage await new test_driver.Actions().pointerDown().pointerMove(300, 300).pointerUp().pointerDown().pointerUp().send(); creates 2 clicks + 0 dblclick in chrome, but 2 clicks + 1 dblclick in Firefox.

It looks like we just have a 640ms timer in marionette to see if we need to increase the clickCount.

We should have a consistent behaviour between browser vendors.

When I read the spec correctly it all ends-up in the implementation specific steps, or?

https://w3c.github.io/webdriver/#dfn-perform-implementation-specific-action-dispatch-steps

So due to the pointer move we probably should reset the click count given that a double click always happens at the same location.

James, am I right?

Yes, I think that would make sense. The spec doesn't really try to define what a double click is. As far as I can tell when using a real mouse we don't emit a double click if the mouse moves significantly so I think it would make sense for our behaviour here to change so that marionette only registers double click if there's no movement.

I sort of have a different opinion. I have a test file which moves the iframe's position a little bit when there's mousedown event hits the iframe.

If I click the button two times, the button does get a dblclick event. The two clicks should have different positions from the iframe's perspective. If I am testing the correct thing, then it means we do generate dblclick events even if the mouse has moved?

I think it depends what you use as the origin of the coordinate system? I suspect the UI is checking for movement in screen coordinates rather than in document coordinates. That would be the same as "can't have a pointerMove between two pointerDowns and still generate a double click".

Yeah, it's screen coordinates. Based on playing around with https://dvcs.w3.org/hg/d4e/raw-file/tip/mouse-event-test.html I think a dblclick is only generated after two clicks with same coords.

With the just refactored code for the ClickTracker on bug 1864614 we still have this problem.

As it looks like it affects the pdf.js tests with WebDriver BiDi (but not CDP) as well. There are a lot of mouse movements in-between the individual mouse clicks, and everything is run within the 640ms timeout for the tracker. As such we emit multi-clicks accidentally.

Reading through the bug I see an agreement that we should reset the counter when the mouse moves.

Sasha, could you have a look at this bug? I'm going to add it to M9 given that is causes issues in pdf.js tests.

Depends on D195093

https://hg.mozilla.org/mozilla-central/rev/291b2a9b817b
https://hg.mozilla.org/mozilla-central/rev/87d12c4bce49
https://hg.mozilla.org/mozilla-central/rev/40f851a3cb9a