Skip to content
Back to skills

Browser Input

ASecurity

Use when a browser or embedded web game must survive Pointer Lock changes, tab visibility, pointer cancellation, touch, focus loss, or gamepad connect/disconnect without stuck actions.

  • 11 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added October 23, 2026
developmentapi

Works with

  • api

Security analysis

A100/100

Scanned October 23, 2026

npx -y skills add jammyfu/open-game-skills --skill browser-input --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Browser Input?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Browser Input
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/jammyfu-browser-input/badge)](https://www.skillsdirectory.com/skills/jammyfu-browser-input)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: browser-input
description: Use when a browser or embedded web game must survive Pointer Lock changes, tab visibility, pointer cancellation, touch, focus loss, or gamepad connect/disconnect without stuck actions.
---

# Browser input

This skill adapts browser/device events into the semantic actions defined by `input-design`. It does not redefine the action grammar.

## Pointer and focus lifecycle

1. Pointer Lock is state, not an assumption. Observe `pointerlockchange`; handle `pointerlockerror`; publish a usable non-lock fallback when core look needs one.
2. On `visibilitychange` to hidden and on relevant window focus loss, synthesize semantic releases/reset for held transient actions. On return, require fresh input edges rather than replaying stale key/pointer state.
3. Treat `pointercancel` and lost pointer capture as termination of the affected pointer gesture. Mobile browser scrolling, app switching, orientation changes or palm rejection can cancel a pointer without `pointerup`.
4. Menu/modal transitions release gameplay look/gesture ownership before widgets consume input.

## Touch and gamepad

5. Track touch/pointer IDs so movement and look can coexist; one canceled pointer must not erase unrelated active pointers unless the platform/browser cancels them too.
6. Handle `gamepadconnected` and `gamepaddisconnected`, but also poll current pads through the runtime's supported Gamepad API path because availability can depend on page focus/user interaction. A disconnected pad releases its held semantic actions.
7. Gamepad button/axis indices are device data. Map through an explicit profile/deadzone layer; do not assume one controller layout for every device.
8. A runtime may not support every browser API equally. Missing Pointer Lock, touch, gamepad or haptics becomes a capability/fallback decision in `platform-targets`, not silent failure.

## Accept

Desktop: deny Pointer Lock, acquire it, press Escape to lose it, alt-tab/hide/return, and disconnect/reconnect a gamepad; no action stays held and look has a declared fallback. Touch: move and look simultaneously, then force `pointercancel` for one pointer and verify the other action remains correct. Record actual browser/device combinations; static event wiring alone is not a behavioral pass.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

View all in development →

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.