Touch/pointer events test results

Some of the more interesting data points from running my various touch/pointer tests on a variety of devices/browsers. All tests carried out manually, trying to get the cleanest possible results (e.g. getting a "clean" tap without any finger movement).

Some of these results first appeared in my presentation Getting touchy - an introduction to touch and pointer events, but have since been retested and are now collated here for easier referencing.

See also Peter-Paul Koch's Touch table, where he tests some further aspects beyond the scope of my tests.

Last updated 26 June 2014. See complete change history.

Contents

• Mobile/tablet touchscreen activation/tap event order
• Mobile/tablet touchscreen with assistive technology event order
• Mobile/tablet touch devices with paired keyboard/mouse event order
• Desktop with touchscreen event order
• Desktop with assistive technology event order
• Desktop with touchscreen and assistive technology event order
• "Faked" event coordinates

Mobile/tablet touchscreen activation/tap event order

Generally, only a single ("sacrificial") mousemove is fired as part of the mouse compatibility events, just to rattle any legacy scripts that may be listening for this event.

There is a bug in WebKit (affecting iOS7.1/Safari and WebView) where mouseenter mouse compatibility event is not being fired correctly - see Bug 128534 - mouseenter mouse compat event not fired when listeners for touch events.

In the touch event model, mouse compatibility events (and final click) are only fired when a single finger is on the touchscreen. As soon as there's two or more (even outside of the element we're listening on), only touch events are fired and mouse compatibility events are suppressed.

There is a bug in current Blink implementations (noticed in Android/Chrome M34, M35 beta, and related Blink-based browsers like Opera) which also suppresses actual touch events if the first touch happened on a region with no touch handlers - see Issue 363321: No touch are ever events fired if the first finger went down in an area with no handler.

If during the tap there is too much movement of the finger (based on browser-specific threshold), this is considered a gesture rather than a tap, and any mouse compatibility events (including click) are generally not fired.

There is a bug in older versions of Blink (noticed in Android/Chrome M34, Android/Opera, Android/Maxthon) where even the slightest movement during a tap results in touchstart, a single touchmove only, and a touchcancel, with no further events being dispatched. This behavior is inconsistent with other implementations (as noted above, the result is usually touchstart, a few touchmove events, a touchend and then - provided the movement was within the threshold - the mouse compatibility and click events). Android/Chrome M35 (beta) seems to have fixed this bug - see Issue 363319: Swiping over a button with touch event handlers results in a single touchmove then touchcancel.

When testing touch events on desktop using developer tools emulation, note there are currently bugs in the order/type of events being fired:

• Chrome: Issue 181204: Emulate touch events - event order different from real devices
• Firefox: Bug 920956 - DevTools touch emulation: suppress regular mouse events, emulate 300ms delay

Mobile/tablet touchscreen with assistive technology event order

Using touch gestures (e.g. swipe left/right, double-tap to activate) and "touch explore".

No assistive technology available (yet) for Firefox OS, Windows Phone 8 or BlackBerry PlayBook.

Moving the focus (swiping left/right and using “touch explore”) will fire a JavaScript focus event – except in Android / Firefox with TalkBack, where focus is only sent as part of the series of events that follow an activation (double-tap). Though perhaps not a problem in practice, it does represent an incompatibility with other implementations - see Bug 1000082 - [AccessFu] When virtual focus is on a button or link, fire actual focus on the element, too, with thanks to Marco Zehe.

Mobile/tablet screenreaders are quite liberal in firing additional blur events when an element is activated – presumably in an attempt to prevent focus-specific CSS styles to "stick" after a user tapped on an in-page link or control. Careful if your code assumes blur means the user has moved away from the focusable element, as the AT focus is actually still there.

There are dramatic differences in the events being fired between gesture navigation and "touch explore" on Android.

There is a bug in WebKit (affecting iOS7.1/Safari and WebView) where mouseenter mouse compatibility event is not being fired correctly - see Bug 128534 - mouseenter mouse compat event not fired when listeners for touch events.

Mobile/tablet touch devices with paired keyboard/mouse event order

iOS does not support paired mouse, paired keyboard only works in same situations as on-screen keyboard (e.g. when prompted to enter a web address, enter data in a text input) unless VoiceOver is also activated (in which case it supports full control, but acts the same as regular VoiceOver with touch gestures).

Firefox OS (ZTE Open) currently does not support paired bluetooth mouse/keyboard. Windows Phone 8 (Nokia Lumia 520) does not support paired bluetooth mouse/keyboard.

Android 2.3.7 only has partial keyboard support. It was not possible to successfully pair a keyboard or mouse with the Android 2.1 HTC Hero test device.

Desktop with touchscreen event order

If during the tap there is too much movement of the finger (based on browser-specific threshold), this is considered a gesture rather than a tap, and any mouse compatibility events (including click) are generally not fired.

Desktop with assistive technology event order

Using traditional TAB / SHIFT+TAB / ENTER keyboard navigation. Notice the faked mouse events (particularly in OS X, when activating the test button with CTRL+⌥ ALT+SPACE as prompted by VoiceOver), which are not fired when assistive technology is not present, and are most likely meant for compatibility with sites that assume mouse interactions.

Included primarily as a point of comparison for the more specific case of desktop with touchscreen and assistive technology.

This table also includes classic Opera 12 (Presto) which has a unique spatial navigation feature (also used in Opera-based TV browsers): using SHIFT+cursor keys, this mode allows to set focus with the keyboard not in a sequential tab order, but based on the relative position of elements in the rendered layout (e.g. using SHIFT+→ to move to the closest focusable element to the right of the current element). Again, for compatibility with mouse-centric sites/scripts, Opera's spatial navigation fires the whole range of mouse events when entering and leaving an element.

When using VoiceOver on OS X, different events are fired depending on how elements are activated – for instance, activating a button with SPACE or ENTER will simply fire click, whereas CTRL+ALT+SPACE (the key combination prompted by VoiceOver) also fires the aforementioned "faked" mouse events.

Opera 12 (Presto) on Windows, OS X and Opera 20 (Blink) on OS X seem to have no (workable) support for assistive technology. ZoomText 10.1 currently not working at all with Chrome (34).

Desktop with touchscreen and assistive technology event order

Using touch gestures (e.g. swipe left/right, double-tap to activate) and "touch explore", instead of traditional TAB / SHIFT+TAB / ENTER keyboard navigation.

Using a desktop screenreader with a touchscreen and touch gestures (swipe left/right and using "touch explore", similar to mobile/tablet screenreaders), none of the tested combinations of browser/AT fired a focus event when moving the focus outline to an element – focus is only sent as a result of a double-tap activation.

Opera 12 (Presto) on Windows seems to have no support for assistive technology. Chrome+ChromeVox does not currently support touch swipes/gestures on desktop.

"Faked" event coordinates

As noted in the "Desktop with assistive technology" and "Desktop with touchscreen and assistive technology" sections, even when not using a traditional pointing device, certain combinations of browser/AT generate "fake" mouse events for compatibility with legacy sites/scripts that hang behavior on traditional mouse events.

As part of an admittedly philosophical discussion on whether or not setting focus with a keyboard or screenreader (jumping from one focusable element to the next, usually in linear tab order) could also be considered an act of "pointing" (and as such should generate pointer events - see Bug 24786 - ACTION-64: Propose a non-normative note re the keyboard compat issue), I tested if these "faked" events, as well as the final click, also carry any coordinates in their event object.

Any combinations of browser/AT not listed in this table do not generate "fake" mouse events, and any traditional focus, click, blur events they do fire do not contain any coordinates in their event object, as would be the case with regular keyboard interactions.

One interesting result which is not included in this table (as it's likely a bug): even for traditional keyboard navigation (with and without Narrator), IE11 passes along coordinates in the event object for the click event when an element is activated. However, these coordinates are meaningless - see Bug 856583: IE11 click event has strange/illogical screenX/screenY, clientX/clientY, pageX/pageY coordinates:

• using ENTER screenX/screenY are 0
• using SPACE screenX/screenY are screen coordinates of top left corner of the browser viewport
• clientX/clientY and pageX/pageY contain negative values, the inverse of the coordinates of the top left corner of browser viewport