Measured with Craft v0.0.107 (published darwin-arm64) on macOS 27.0, M3 Pro, using the Stacks probe harness (`buddy desktop:probe`, stacksjs/stacks#877). The input was genuine OS-level mouse and keyboard events posted to the window, so the page saw `isTrusted` gestures.
- `Element.requestPointerLock()` from a real click fires `pointerlockerror`.
- Clicked after leaving element fullscreen, it fails with "requires the window to have focus", although the click itself landed in the window.
- Element fullscreen from the same kind of click works (enabled in #332).
Pointer lock is what first-person and drag-heavy canvases use (three.js PointerLockControls, any FPS-style camera), so a game or 3D viewer hosted in a Craft window cannot capture the mouse today.
WKWebView has no public preference for this. WebKit routes the request through the UI delegate, and without a handler it refuses. Worth checking which delegate entry point the macOS SDK on the CI runners exposes, and whether it can be adopted without private API (a Store build must not use SPI). If it can't, documenting "pointer lock is unavailable in Craft windows" is the honest outcome, and the Stacks capability matrix already records it that way.
The focus message after leaving fullscreen may be a separate, smaller bug: the window should regain key status for its web view when element fullscreen ends.