Skip to content

Fix trackpad canvas wheel ownership across idle hover gaps#219

Merged
DeadWaveWave merged 3 commits intomainfrom
fix/trackpad-canvas-moving
May 1, 2026
Merged

Fix trackpad canvas wheel ownership across idle hover gaps#219
DeadWaveWave merged 3 commits intomainfrom
fix/trackpad-canvas-moving

Conversation

@DeadWaveWave
Copy link
Copy Markdown
Owner

💡 Change Scope

  • Small Change: Fast feedback, localized UI/logic, low-risk.
  • Large Change: New feature, cross-boundary logic, runtime-risk (persistence, IPC, lifecycle, recovery).

📝 What Does This PR Do?

Fixes workspace-canvas trackpad wheel ownership so canvas panning does not get stolen by a terminal/node after the pointer happens to come to rest above that node.

The key behavior change is intentional:

  • if a canvas-owned trackpad pan settles while the pointer is hovering a terminal, the next two-finger scroll still belongs to the canvas as long as the user has not expressed new pointer intent;
  • ownership only transfers back to the hovered node after an explicit pointer retarget signal such as pointer movement or pointer down.

This keeps canvas panning stable without turning the fix into a per-node patch.


🏗️ Large Change Spec (Required if "Large Change" is checked)

1. Context & Business Logic

The existing implementation only treated wheel ownership as a contiguous burst problem. Once the gesture-gap timeout elapsed, ownership fell back to hit-testing the current hover target, which meant a terminal could steal the next trackpad pan even if the user had done nothing except pause briefly.

This PR upgrades the wheel session model so the canvas keeps a settled owner preference after the active capture window ends. A later explicit pointer retarget is required before wheel ownership can move back into a hovered terminal/node.

2. State Ownership & Invariants

Owner: renderer workspaceCanvas wheel-gesture session state (trackpadGestureLockRef plus the derived capture-active UI flag).

Invariants:

  • A canvas-owned trackpad wheel session must not retarget to a node merely because hover crossed into that node.
  • A gesture gap ends active capture, but it does not erase the canvas owner preference by itself.
  • Returning wheel ownership to a node requires explicit pointer intent, not passive hover.

3. Verification Plan & Regression Layer

Regression layers:

  • Unit: tests/unit/contexts/wheelGestures.spec.ts
  • Hook-level renderer test: src/contexts/workspace/presentation/renderer/components/workspaceCanvas/hooks/useTrackpadGestures.spec.tsx
  • E2E: tests/e2e/workspace-canvas.trackpad-gestures.spec.ts

Verification run:

  • pnpm pre-commit
  • pnpm test -- --run tests/unit/contexts/wheelGestures.spec.ts src/contexts/workspace/presentation/renderer/components/workspaceCanvas/hooks/useTrackpadGestures.spec.tsx
  • pnpm test:e2e tests/e2e/workspace-canvas.trackpad-gestures.spec.ts --project electron --reporter=line

✅ Delivery & Compliance Checklist

  • My code passes the ultimate gatekeeper: pnpm pre-commit is completely green.
  • I have signed the CLA if required (see CLA.md).
  • I have included new tests to lock down the behavior (or explicitly stated why it's untestable).
  • I have strictly adhered to the DEVELOPMENT.md architectural boundaries.
  • I have attached a screenshot or screen recording (if this touches the UI).
  • I have updated the documentation accordingly (if adding a feature or changing a contract).

📸 Screenshots / Visual Evidence

Not attached via CLI. The behavior is covered by the new E2E regression, and I can add a recording in the GitHub UI if needed.

@DeadWaveWave DeadWaveWave merged commit 3ba6f16 into main May 1, 2026
7 checks passed
@DeadWaveWave DeadWaveWave deleted the fix/trackpad-canvas-moving branch May 1, 2026 16:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant