9 August 2014
The life-cycle of a browser's touch sequence consists of a
Here is a minimal example. Load this page on a touch-enabled device. Use this QR code if that helps.
Touch anywhere except the red target, move your finger, then lift up. You will see the event log record a start, several moves, and an end. No problem.
Next, do the same thing with the red target. The target is programmed to delete itself. You will see the event log record a start. And that's it -- no moves, no end.
It is worth pointing out that all these events are attached to the document, not the target (view source for details). The event handlers are still there, but as soon as the original target vanishes the browser stops dispatching new events. By contrast, mouse events (mousedown, mousemove, mouseup) keep firing as long as the object they are attached to exists.
This behaviour is consistent across Chrome and Firefox on Android, and in Safari on iOS. The W3 recommendation for touch events states (sections 5.6-5.7) that the target property for touchmove/touchstart must be the same as the target property for touchstart. To comply with this and not set the target to be something that may have been garbage collected, the browsers have chosen to drop these events on the floor. Thus the behaviour observed is not specifically called for by the spec, but is instead a non-intuitive emergent behaviour.
Many thanks to co-worker Shawn Brenneman for helping to figure this one out. The bug that revealed this was buried deeply in Blockly and had me totally stumped. With luck this page will prevent someone from having to go through the same process.