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//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