Closed Bug 1681076 Opened 3 years ago Closed 3 months ago

dblclick generated despite the cursor position has moved


(Remote Protocol :: Agent, defect, P2)



(firefox122 fixed)

122 Branch
Tracking Status
firefox122 --- fixed


(Reporter: sefeng, Assigned: Sasha)


(Blocks 1 open bug)


(Whiteboard: [webdriver:m9], [wptsync upstream][webdriver:relnote])


(2 files)

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?

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?

Flags: needinfo?(james)

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.

Flags: needinfo?(james)

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 I think a dblclick is only generated after two clicks with same coords.

Whiteboard: [webdriver:triage]
Priority: -- → P3
Whiteboard: [webdriver:triage]
Product: Testing → Remote Protocol

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.

Blocks: 1792089, 1860992
Component: Marionette → Agent
Depends on: 1864614
Flags: needinfo?(aborovova)
Priority: P3 → P2
Whiteboard: [webdriver:m9]
Assignee: nobody → aborovova
Flags: needinfo?(aborovova)
Pushed by
[remote] Reset ClickTracker when pointer is moved. r=webdriver-reviewers,whimboo
[wdspec] Add tests for double click when pointer is moved between clicks. r=webdriver-reviewers,whimboo
Created web-platform-tests PR for changes under testing/web-platform/tests
Whiteboard: [webdriver:m9] → [webdriver:m9], [wptsync upstream]
Points: --- → 2
Pushed by
Remove testdriver/actions/mouseClickCount.html subtest as it's now passing. a=test-only
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 122 Branch
Upstream PR merged by moz-wptsync-bot
Whiteboard: [webdriver:m9], [wptsync upstream] → [webdriver:m9], [wptsync upstream][webdriver:relnote]
You need to log in before you can comment on or make changes to this bug.