[React Doctor] Marked 7 scroll and touchstart listeners as passive

[github-actions]

Marked 7 scroll and touchstart listeners as { passive: true } — unblocks main-thread scrolling on these handlers, none of which call preventDefault()

Browsers treat scroll/touchstart listeners as blocking by default — the compositor waits on each event until JS confirms it isn't going to call preventDefault(). All 7 handlers here are pure observers (re-measuring viewport, syncing positions, dismissing overlays); none gate scrolling. Flipping them to { passive: true } lets the browser scroll without that wait.

Changes

• apps/website/components/mobile-demo-animation.tsx:306 — client-passive-event-listeners: visualViewport scroll → { passive: true } (handler is measureElementPositions, pure measurement)
• apps/website/components/ui/scrollable.tsx:46 — client-passive-event-listeners: element scroll → { passive: true } (updateScrollbar only sets state from scrollHeight/clientHeight)
• packages/react-grab/src/core/index.tsx:2893 — client-passive-event-listeners: merge passive: true into the existing { signal } options object
• packages/react-grab/src/components/toolbar/index.tsx:520 — client-passive-event-listeners: visualViewport scroll → { passive: true } (handleResize schedules a recalc, no preventDefault)
• packages/react-grab/src/components/selection-label/index.tsx:152 — client-passive-event-listeners: visualViewport scroll → { passive: true } (handleViewportChange just bumps a signal)
• packages/react-grab/src/utils/create-anchored-dropdown.ts:97 — client-passive-event-listeners: visualViewport scroll → { passive: true } (handleViewportChange is a batched setter)
• packages/react-grab/src/utils/register-overlay-dismiss.ts:52 — client-passive-event-listeners: merge passive: true into the existing { capture: true } options (handleClickOutside only calls onDismiss)

---

---

Note

Low Risk
Observer-only listeners with no preventDefault; passive flag is safe and limits scope to scroll performance.

Overview
Marks seven scroll and touchstart listeners as { passive: true } across the marketing site and react-grab so the browser can scroll without waiting on JS that never calls preventDefault().

Website: visualViewport scroll in the mobile demo (re-measure layout) and element scroll in Scrollable (custom scrollbar sync).

Library: visualViewport scroll on the selection label, toolbar, anchored dropdowns, and core overlay (viewport/version sync); touchstart on overlay dismiss is passive alongside existing capture, while mousedown stays non-passive where needed.

Behavior is unchanged—these handlers only measure, reposition, or dismiss.

^{Reviewed by Cursor Bugbot for commit ef5d264. Bugbot is set up for automated code reviews on this repo. Configure here.}

---

Summary by cubic

Marked 7 scroll and touchstart listeners as passive to remove main-thread blocking during scroll. Improves scroll responsiveness without behavior changes, since none of these handlers call preventDefault.

• Performance
  • Added { passive: true } to visualViewport scroll handlers (toolbar, selection label, mobile demo, dropdown anchoring, core init).
  • Added { passive: true } to element scroll in Scrollable.
  • Kept existing options intact by merging with signal and { capture: true } (overlay dismiss touchstart).

^{Written for commit ef5d264. Summary will update on new commits.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
react-grab-storybook	Ready	Preview, Comment	May 30, 2026 3:48pm
react-grab-website	Ready	Preview, Comment	May 30, 2026 3:48pm

[vercel]

Additional Suggestions:

1. Event listener for touchstart is added with { capture: true, passive: true } but removed with only { capture: true }, causing the listener to not be properly removed

2. The visualViewport scroll event listener is registered with { passive: true } but removed without the passive option, preventing proper cleanup and causing a memory leak

3. Missing { passive: true } option in removeEventListener causes visualViewport scroll listener to not be properly removed, creating a memory leak

4. addEventListener and removeEventListener options mismatch causes memory leak in event listener cleanup

5. visualViewport scroll event listener is not properly removed due to mismatched addEventListener/removeEventListener options, causing a memory leak