This diagram has a <text> and <circle> inside a <g>, and the <g> has an event logger. The reason I have nested elements is that you can see how pointerover/pointerout differs from pointerenter/pointerleave.
The second test shows the event data: (pointer type can be mouse
, pen
, touch
; pressure can be 0 to around 1, and mac trackpads can send pressure data, but only on Safari, using these non-standard events and properties[1], and it’s not scaled 0 to 1)
https://patrickhlauke.github.io/touch/[2] has a lot of touch event tests
Using preventDefault()
on a pointer event should cancel the corresponding mouse event or touch event.
https://developer.mozilla.org/en-US/docs/Web/API/Force_Touch_events[3] seems to be active on my mac laptop (touchpad is force sensitive) but not on my phone
On iPhone I don’t get a TouchEvent.force or PointerEvent.pressure. On iPad I get both when using the Apple Pencil. On Android I do get that value in both Chrome and Firefox.
Chrome has a bug about[4] the up event not following the contextmenu, and a followup bug[5] and related bug[6] about enter/leave events. The mouseleave
event doesn’t get sent on contextmenu
.
https://github.com/WICG/auxclick/issues/1[7] - says contextmenu should be after mousedown on linux, after mouseup on windows, and auxclick should be after contextmenu. But auxclick runs before contextmenu on windows.
javascript.info[8] has a demo of click event logging but theirs does not run into the same problem as I have with the contextmenu. It’s because they trap the contextmenu
event so the up event is correct.
https://w3c.github.io/uievents/#event-type-auxclick[9]
https://bugs.chromium.org/p/chromium/issues/detail?id=1264930[10]]] → a contextmenu
should produce a PointerEvent that has .pointerId
the same as the id of the event that produced that menu. It is fixed on Chrome but it is undefined on Firefox, because Firefox 110 and Safari 13 produce a MouseEvent not a PointerEvent[11].
https://bugs.chromium.org/p/chromium/issues/detail?id=958776[12] → asks for contextmenu
to fire pointercancel
. It can’t fire pointerup
because that looks like a click
.
https://bugs.chromium.org/p/chromium/issues/detail?id=958776[13] → reports that in Chrome 21, right click does fire mouseup
but only if it’s quick; otherwise it doesn’t fire mouseup
.
https://bugs.chromium.org/p/chromium/issues/detail?id=627889[14] → chrome decided not to issue pointercancel after a contextmenu
https://bugs.chromium.org/p/chromium/issues/detail?id=149091[15] lists platform and browser differences as of 2017.
https://twitter.com/kaleidealogy/status/1430871635968634880[16] → pointer down and pointer up may not be on the same button. It says pointermove
will get called on subsequent button changes!! This is different from mouse events!! https://w3c.github.io/pointerevents/#chorded-button-interactions[17]
I can’t seem to see button4 or button5 in these events.
https://navidz.github.io/pointerrawupdate.html[18] - experimental, in chrome/edge but not safari/firefox https://caniuse.com/mdn-api_element_pointerrawupdate_event[19]
https://www.w3.org/TR/pointerevents3/#mapping-for-devices-that-support-hover[20]
lostpointercapture
might be useful to track
List of pointer event tests and whether they pass in each browser and each device type[21]
Latency in reading pointer move events[22]
Patrick Dubroy has a blog post about alternatives to the callback model of event processing[23]