Clarify how the double click tracking should work in the actions

[lutien]

At the moment, the spec doesn't specify how the double (or triple click, etc.) tracking should work in the actions. For example, it's not clear, if it should be possible to simulate a double click event by sending two separate commands with individual clicks.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Clarify how the double (triple) click tracking should work in the actions.

The full IRC log of that discussion

<AutomatedTester> topic: Clarify how the double (triple) click tracking should work in the actions
<AutomatedTester> github: https://github.com/w3c/webdriver/issues/1772
<AutomatedTester> whimboo: this is another issue for actions. I have been checking different frameworks
<AutomatedTester> ... and they do things different ways for solving this e.g. in same chain or different chains
<jgraham> q+
<jimevans> q+
<AutomatedTester> ... so we should solve this to only allow in chain or not especially since separate chains could be tricky to see what people mean
<AutomatedTester> ack next
<sadym> q+
<simons> q+
<jimevans> q-
<AutomatedTester> jgraham: do we know what existing implementations are doing here? if I were building this this myself it would be in the same chain especially around network latency
<orkon> q+
<AutomatedTester> ... I am happy for state to be cancelled at the end of the chain but that might require client changes and that would be problematic
<AutomatedTester> ack next
<AutomatedTester> sadym: there is a potential if the user wants to do 2 single clicks. THey will have to wait a certain time accoridng to the OS
<AutomatedTester> ... so we need to be aware of how that plays out
<AutomatedTester> q?
<AutomatedTester> ack next
<AutomatedTester> simons: I think most clients would do the right thing here in a single chain. I quite like jgraham's suggestion here of cancelling state at the end of the chain
<AutomatedTester> ack next
<jgraham> (I should say I don't know how easy that is to implement)
<jgraham> q+
<AutomatedTester> orkon: how would we specify this behaviour in the spec? Do we want to improve how events are specified?
<AutomatedTester> ack next
<orkon> q+
<whimboo> q+
<AutomatedTester> jgraham: from the spec point of view. It is quite reasonable for the event must not have the double click attr have it set unless it's part of the action chain and the previous item was a pointer down?
<AutomatedTester> q?
<AutomatedTester> ack next
<AutomatedTester> orkon: I think the complexity is from there being a new event not just another click
<AutomatedTester> ... and it can be challenging for the event to be doing the right order
<AutomatedTester> ... if we don't have a "it must not have" we are making our own rules here
<AutomatedTester> q?
<AutomatedTester> ack next
<AutomatedTester> whimboo: one more comment to jgraham is that it's not only related to the time but it's also about the location of the mouse. E.g. a click, move 1 px, click won't be seen as double click even if it takes the same time as click, click
<AutomatedTester> q?
<AutomatedTester> consensus: we are going to have double clicks in a single chain and clear state at the end of the chain. Also need to check if this might break clients

[whimboo]

The consensus of the W3C meeting as minuted in the last comment was:

consensus: we are going to have double clicks in a single chain and clear state at the end of the chain. Also need to check if this might break clients

[OrKoN]

I think one use case that we did not discuss is:

1. Trigger mousedown.
2. Evaluate a script to check the element is correctly reacting to mousedown.
3. Trigger mouseup.
4. Assert that the click is dispatched on the element.

I think this would not be possible right now because mousedown and mouseup are required to be in the same action chain?

P.S. I cannot recall if we discussed it so bringing it up just in case. I think we discussed double clicks and triple clicks specifically but I wonder if single clicks across action chains would also be affected?

[whimboo]

If we clear the input state at the end of the action chain as mentioned in the meeting notes we would certainly release the mouse button before the evaluate script will run. It also means the click will be emitted before the evaluation, which might not be expected.

It might be good to get some wpt tests added to see which of these scenarios might not work so that we may have to change our decision.

[OrKoN]

I think that might be fine to release dbl clicks and triple clicks in the end of the chain but it sounds like doing the same for other events might be breaking and unexpected. Would it also apply to key down events? That would basically mean that there is no way to only trigger a mouse down/key down event in isolation? That would probably be fine but since you also cannot inspect the state in between actions, how can one test that the site responds correctly to mousedown/keydown?