Closed Bug 1448487 Opened 6 years ago Closed 6 years ago

click actions on different elements trigger wrongly dblclick event

Categories

(Remote Protocol :: Marionette, defect)

59 Branch
defect
Not set
normal

Tracking

(firefox59 fix-optional, firefox60 affected, firefox61 affected)

RESOLVED DUPLICATE of bug 1430851
Tracking Status
firefox59 --- fix-optional
firefox60 --- affected
firefox61 --- affected

People

(Reporter: pascal, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180315233128

Steps to reproduce:

In this example, first on "clear" is clicked, then a click on a different element is issued.

(Using Selenium 3.11.0, Geckodriver 0.20, Firefox 59, 60 or 61):

WebDriver driver = new FirefoxDriver();
driver.get("http://unixpapa.com/js/testmouse.html"); // Open test page


final WebElement webElement = driver.findElements(By.tagName("a")).get(0); // "click here to test"
final WebElement clearWebElement = driver.findElements(By.tagName("a")).get(1); // "clear"

Actions builder = new Actions(driver);
builder.moveToElement(clearWebElement);
builder.click(); // click on "clear"
builder.moveToElement(webElement);
builder.click(); // click on "click here to test"
builder.perform();

// Output event log
final WebElement textedit = driver.findElements(By.tagName("textarea")).get(0);
System.out.println(textedit.getAttribute("value"));



Actual results:

Output:

mousedown   which=1 button=0 buttons=1
mouseup     which=1 button=0 buttons=0
click       which=1 button=0 buttons=0
dblclick    which=1 button=0 buttons=0

So it seems as if the first click action (on a different element) is counted to produce a dblclick event after the first. Same result when using two action sequences:

Actions builder = new Actions(driver);
builder.moveToElement(clearWebElement);
builder.click();
builder.perform();

// Add this here to workaround the bug: Thread.sleep(550);
builder = new Actions(driver);
builder.moveToElement(webElement);
builder.click();
builder.perform();


Expected results:

Output:

mousedown   which=1 button=0 buttons=1
mouseup     which=1 button=0 buttons=0
click       which=1 button=0 buttons=0
Attached file TRACE Logfile
Maja, don't we differentiate between individual clicks for different elements? That shouldn't cause a double click event to be triggered. So maybe a fallout from bug 1385476?
Flags: needinfo?(mjzffr)
No, it's a known gap in the implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=1430851
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Flags: needinfo?(mjzffr)
Resolution: --- → DUPLICATE
Just a FYI: The Java API here is horrible.  A click to hold down
and drag and a click to release?  I think it is meant to be
pointerDown, move, pointerUp.  Otherwise this doesn’t make any
sense.
Andreas, I cannot see a shortcoming of the Java API here, no drag is involved, just two subsequent clicks on two different links:

[{..."type":"pointerMove",...},{"button":0,"type":"pointerDown"},{"button":0,"type":"pointerUp"},{..."type":"pointerMove",...},{"button":0,"type":"pointerDown"},{"button":0,"type":"pointerUp"}]

And as described in my original post, it does not make any difference if both clicks are performed in one or in two action sequences. Only timing is relevant - if you place a 550 ms pause between your clicks, it's fine (but that won't even a real user do if the targets are next to each other).
My point is that the Java API does not reflect what the action
sequences in WebDriver are actually _doing_.  A click, by necessity,
consists of a key down and a key up input: you press the mouse
button down and release it to generate a click.

The Java client does generate the correct output, as is exemplified
by the action sequence you displayed, but there remains a cognitive
dissonance between its use of ‘click’ to mark the beginning of what
is essentially a pointerDown → pointerMove → pointerUp sequence.
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: