Gesture handling in XOM is touch and pointer interpretation inside the web client: drags that move content, taps that reveal or hide controls, and the guards that keep one from being mistaken for the other. Camera-based recognition of hand or body gestures is a different capability and is not present in the reviewed codebase.
01Gestures in the feed
The social feed implements a drag gesture on multi-image posts. A carousel track responds to touch start, move and end, and to the equivalent mouse events, translating the track horizontally as the finger or pointer moves and settling on a slide when the gesture ends. Because both event families are wired to the same handlers, the same interaction works on a phone and on a desktop with a pointer, and an interrupted drag — the pointer leaving the element mid-gesture — is treated as a gesture end rather than left hanging.
02Gestures in the live player
The mobile live player is the most deliberate gesture surface in the platform. Tapping the video toggles the control overlay, and the implementation guards against a common failure: it records when the touch began and counts intervening move events, so a drag or scroll is not misread as a tap. Controls auto-hide again after a period of inactivity.
A second gesture is dismissal. When the overflow menu is open, a touch anywhere outside the control cluster closes it, which avoids the trap of a menu that can only be closed by finding its own close affordance.
Alongside touch, the player ships a keyboard shortcut layer with a default shortcut set and a panel that lists the bindings, dismissible by clicking outside it or pressing Escape.
03Specified but not yet built
The mobile layout plan describes swipe gestures for navigating between the bottom tab destinations — home, social, create, messages and profile — as part of a mobile-optimised, single-column build of the feed. That work is scoped as a later phase and should be treated as planned rather than shipped.
At the platform level, the settings specification defines an accessibility options step handled by an accessibility controller, which is where alternative input preferences would belong. The contents of that controller are not enumerated in the sources reviewed.