Right, but the article doesn't explain why they cared whether it was keyboard or mouse activation. The linked WebKit bug goes into more detail, but it's still l

Right, but the article doesn't explain why they cared whether it was keyboard or mouse activation. The linked WebKit bug goes into more detail, but it's still lacking an explanation of why alternative, more common and widely deployed strategies (like having a capturing keyup event that triggers earlier in the render loop) wouldn't be a better idea instead. Also, if you really want to determine whether a MouseEvent is "real" or "synthetic", and you don't want to worry about when mouse events are triggered relative to keyboard events in the event loop (although it doesn't seem very hard to keep track of), it seems like you can use the current click count (i.e., event.detail). This works on both Chrome and Safari—it's 1 for mouse clicks, and 0 for keyboard "clicks", but the spec text is also a little contradictory and under-specified: the "click" event handler says that "the attribute value MUST be 1 when the user begins this action and increments by 1 for each click" (https://w3c.github.io/uievents/#event-type-click https://w3c.github.io/uievents/#event-type-click) but it also says "This MUST be a non-negative integer indicating the number of consecutive clicks of a pointing device button within a specific time" (https://w3c.github.io/uievents/#current-click-count https://w3c.github.io/uievents/#current-click-count), and the definition of "pointing device button" seems to exclude synthetic keyboard events (since those are handled separately)