Guard animateTarget window access in non-browser runtimes (#3735) - #3751
Guard animateTarget window access in non-browser runtimes (#3735)#3751mattgperry wants to merge 3 commits into
Conversation
Several motion-dom functions accessed `window` without a `typeof window` guard, throwing in non-browser JS runtimes — or when `window` is shadowed to undefined by an IIFE wrapper (e.g. Lynx's web runtime). The immediate crash reported was `animateTarget` reading `window.MotionHandoffAnimation`, but the same unguarded access existed across projection, keyframe resolution, computed-style reads, gestures, resize handling and the scroll-timeline support checks. Add `typeof window !== "undefined"` guards at each site, matching the existing pattern in render/utils/reduced-motion. `typeof` never throws on an undefined binding, and every guard evaluates to true in a browser, so existing behaviour is unchanged. Fixes #3735 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Greptile SummaryThis PR adds
Confidence Score: 4/5Safe to merge for browser consumers; gesture handlers in hover.ts and press/index.ts have a minor state-stuck edge case that only affects non-browser runtimes with active pointer events All guards are additive no-ops in browsers. The only non-trivial behavioural gap is in hover.ts and press/index.ts: when window is undefined but pointer events can still fire (e.g., Lynx's UI layer), the window-level pointerup/pointercancel cleanup listeners are never registered, so isPressed and isPressing can get stuck after a pointerdown. This doesn't affect any browser path and is a degraded-but-non-crashing state in the exact exotic environments this PR targets. gestures/hover.ts and gestures/press/index.ts — the isPressed/isPressing cleanup gap is worth a follow-up if Lynx (or similar UI-capable runtimes) is a first-class target Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[animateTarget called] --> B{typeof window !== 'undefined'?}
B -- No --> C[Skip MotionHandoffAnimation check\nReturn no-op animation]
B -- Yes --> D[Read window.MotionHandoffAnimation\nProceed normally]
E[hover / press pointerdown] --> F{typeof window !== 'undefined'?}
F -- No --> G[Set isPressed=true\nSkip window pointerup/cancel listeners\nstate may get stuck]
F -- Yes --> H[Register cleanup on window\nNormal gesture flow]
I[createWindowResizeHandler] --> J{typeof window !== 'undefined'?}
J -- No --> K[Return early\nwindowResizeHandler stays undefined]
J -- Yes --> L[Register resize listener\nNormal resize flow]
M[supportsScrollTimeline] --> N{typeof window !== 'undefined'?}
N -- No --> O[Return false / memoize false]
N -- Yes --> P[Check window.ScrollTimeline\nMemoize result]
Reviews (1): Last reviewed commit: "Guard window access for non-browser runt..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| const onPointerDown = () => { | ||
| isPressed = true | ||
| window.addEventListener( | ||
| "pointerup", | ||
| onPointerUp as EventListener, | ||
| eventOptions | ||
| ) | ||
| window.addEventListener( | ||
| "pointercancel", | ||
| onPointerUp as EventListener, | ||
| eventOptions | ||
| ) | ||
| if (typeof window !== "undefined") { | ||
| window.addEventListener( | ||
| "pointerup", | ||
| onPointerUp as EventListener, | ||
| eventOptions | ||
| ) | ||
| window.addEventListener( | ||
| "pointercancel", | ||
| onPointerUp as EventListener, | ||
| eventOptions | ||
| ) | ||
| } |
There was a problem hiding this comment.
isPressed = true
When window is undefined (e.g., Lynx's main-thread runtime), onPointerDown sets isPressed = true but skips registering the pointerup/pointercancel cleanup on window. The only path that resets isPressed = false is onPointerUp, which is only registered on window. Subsequent pointerleave events will therefore always take the deferred-hover-end branch (deferredHoverEnd = true; return) and never call endHover, leaving the element permanently stuck in a "hovering while pressed" state for the rest of the element's lifetime. The same pattern exists in press/index.ts where isPressing can retain the target indefinitely once a pointerdown fires without a corresponding window-level cleanup.
Limit non-browser handling to animateTarget and use a module-level isBrowser flag so the animation loop avoids repeated environment checks.
mattgperry
changed the title
1 participant
Bug
animateTargetaccessedwindow.MotionHandoffAnimationdirectly, throwing whenwindowis unavailable or shadowed toundefined, as in the reported Lynx runtime.Fix
Define
isBrowseronce at module initialization and use it to guard the handoff lookup. This keeps the fix limited to the reported crash and avoids repeating an environment check for each animated value.Test
A Node-environment regression test verifies that
animateTargetno longer throws withoutwindow.Verification
yarn build --filter=motion-dompassesFixes #3735