Skip to content

fix(mobile): keep the pane menu off a dragged text selection on Android - #1159

Merged
devswha merged 1 commit into
mainfrom
fix/touch-selection-pane-menu
Oct 15, 2026
Merged

devswha merged 1 commit into
mainfrom
fix/touch-selection-pane-menu

Conversation

@devswha

@devswha devswha commented Oct 15, 2026

Copy link
Copy Markdown
Owner

Change

On Android Chrome, a long press followed by dragging the selection opened the pane's menu (Rename pane, Split right…) over the phone's Copy toolbar. A long press alone was fine.

Chrome sends two contextmenu events for that gesture: one typed touch when the long press starts, and a second typed mouse, with no pointerdown of its own, when the dragged selection ends. #838 trusted the pointer type whenever there was one, so the second one counted as a right-click. The last press now decides: after a touch, a contextmenu is the app's only once a mouse press or a key has come since (PaneCanvas's touchPress, which a mouse pointerdown and any keydown already reset).

Validation

  • Reproduced on the owned API 36 Pixel 7 emulator (Chrome 133) with native touches (adb input touchscreen motionevent: hold 900 ms, drag, lift) over a chat message in the demo app. Before: the events were contextmenu (touch), pointercancel, then contextmenu (mouse, target .pane-frame), and "Pane actions" opened. After: same events, the selection stays and only Chrome's toolbar shows.
  • scripts/touch-long-press-demo-regression.ts gains a drag-select case (a touch press, then a contextmenu typed mouse). It fails on main and passes here; the keyboard and right-click cases still open the menu.
  • bun run check fast passes.

🤖 Generated with Claude Code

Android Chrome ends a dragged selection with a second contextmenu typed
"mouse", with no press of its own. The #838 guard trusted the pointer
type when there was one, so that event opened the pane's menu over the
phone's Copy toolbar. The last press decides now: after a touch, only a
mouse press or a key makes a contextmenu the app's.

Reproduced and checked on the owned API 36 emulator (Chrome 133): a
long press dragged across a chat message opened "Pane actions" before,
and leaves only the selection and Chrome's toolbar after.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Oct 15, 2026 •

Copy link
Copy Markdown

Review in Change Stack →

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration
  • Configuration used: Repository: devswha/herdr-web-ui/.coderabbit.yaml
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 235f2eae-939d-45b0-a74a-b6691b3c256a
📥 Commits

Reviewing files that changed from the base of the PR and between b8c810b and f2e3579.

📒 Files selected for processing: 3
  • changelog.d/touch-drag-select-pane-menu.md
  • scripts/touch-long-press-demo-regression.ts
  • src/components/PaneCanvas.tsx

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 1 remain after this review.

📝 Summary

Summary by CodeRabbit

  • Bug Fixes
    • On Android, lifting a finger after dragging to select text no longer opens the pane menu. Copy and the phone’s text-selection menu remain available in front.

The pane context handler now ignores context-menu events while a touch or pen press is recorded. A regression case covers a mouse-typed context-menu event after dragged text selection.

Changes: Touch selection context-menu handling

Layer / File(s) Summary
Suppress context menus during touch interactions
src/components/PaneCanvas.tsx, scripts/touch-long-press-demo-regression.ts, changelog.d/touch-drag-select-pane-menu.md
The handler ignores context-menu events while a touch or pen press is recorded. The regression script checks the dragged-selection event. The changelog describes the Android pane selection behavior.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Low

Merge Risk: ⚪ Minimal · up to f2e35

The touch-owned selection menu remains available, while later mouse or keyboard input can still open the pane menu. No material merge risk remains.

Pre-merge checks: Passed 5
Passed Passed checks: 5 passed
Check name Status Explanation
Title check Passed The title clearly and concisely describes the Android fix that prevents the pane menu from opening over a dragged text selection.
Description check Passed The description includes the problem, cause, resulting behavior, detailed validation steps, regression coverage, and check results. It follows the required Change and Validation sections.
Docstring Coverage Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 2 files. (1 skipped: 1 …
Linked Issues check Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
📝 Generate docstrings
  • Commit to this branch
  • Create a new PR
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@devswha
devswha merged commit 67f66e1 into main Oct 15, 2026
9 checks passed
@devswha
devswha deleted the fix/touch-selection-pane-menu branch October 15, 2026 08:02
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