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.
auxclick[9] event fires instead of click event for non-primary buttons, since Chrome 55 (2017), Firefox 53 (2017), Safari 18.2 (2024)
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]. Safari 18.2 produces a PointerEvent.
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 until 2025 for firefox[19]https://caniuse.com/mdn-api_element_pointerrawupdate_event[20]
https://www.w3.org/TR/pointerevents3/#mapping-for-devices-that-support-hover[21]
-
lostpointercapturemight be useful to track
List of pointer event tests and whether they pass in each browser and each device type[22]
Latency in reading pointer move events[23]
Patrick Dubroy has a blog post about alternatives to the callback model of event processing[24]
https://groups.google.com/a/mozilla.org/g/dev-platform/c/CoBboR86WnM/m/AZiPy3mWEwAJ[25] “Pointer Events defines click, auxclick, contextmenu event target should be the same target as its source event if and only if the source event is a pointerdown or a pointerup and the pointer is captured at dispatching the source event (the source event of contextmenu may be pointerdown, which depends on when the OS dispatches the native contextmenu).”