fix(desktop): stop Linux context menus from activating an item on open#3868
fix(desktop): stop Linux context menus from activating an item on open#3868xxashxx-svg wants to merge 1 commit into
Conversation
On Linux, Chromium fires contextmenu on right-button PRESS (Windows fires it on release), so the native menu pops up while the button is still physically held. The menu takes the pointer grab, and the tail end of the opening right-click — the button release — lands on whatever item sits under the cursor and activates it. The menu flashes and a random item runs, which also explains the known workaround (hold the right button and drag away before releasing). The earlier fix (pingdotgg#3025) hardened contextMenuFallback.ts, but the desktop app never uses that path — window.desktopBridge routes context menus to the native Electron menu, so the regression survived. Gate the desktopBridge.showContextMenu IPC on pointer release (Linux only): track button state in the preload and defer opening the menu until the press that triggered it is released, matching Windows semantics. Menus opened with no button held (keyboard, click-triggered) are unaffected, as are Windows and macOS. Fixes pingdotgg#3698 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
github-actions
Bot
added
vouch:unvouched
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 94840df. Configure here.
| return new Promise((resolve) => { | ||
| if (pointerButtonsHeld === 0) { | ||
| resolve(); | ||
| return; |
There was a problem hiding this comment.
Blur clears held button state
Medium Severity
On Linux, the context menu delay mechanism can fail. window.blur and pointercancel events prematurely signal button release, even when a pointer button is still physically held. This causes the context menu to appear too early, leading to accidental menu item activation.
Reviewed by Cursor Bugbot for commit 94840df. Configure here.
| const onPointerUp = (event: PointerEvent) => { | ||
| if (event.buttons === 0) { | ||
| settle(); | ||
| } |
There was a problem hiding this comment.
Wait requires all buttons released
Medium Severity
On Linux, waitForPointerRelease only finishes when event.buttons is zero. After a right-click context menu, releasing the secondary button while another pointer button stays down leaves the bitmask non-zero, so the wait never completes on pointerup and the native menu may not open until focus is lost or every button is released.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 94840df. Configure here.
ApprovabilityVerdict: Needs human review This Linux-specific context menu fix has two unresolved review comments identifying potential logic issues: premature resolution on blur/pointercancel events, and multi-button scenarios blocking menu display. These edge case concerns warrant human review before merging. You can customize Macroscope's approvability policy. Learn more. |
1 participant
Fixes #3698
What
On Linux, right-clicking a project/thread in the sidebar makes the context menu flash open and instantly close, with a random menu item activated as if clicked (regression of #285 — still present in v0.0.28 despite the #3025 fix).
Why it happens
Two facts combine:
localApi.tsroutes context menus throughwindow.desktopBridge.showContextMenu→ IPC → the native Electron menu (ElectronMenu.ts) whenever the bridge exists — which on desktop is always. ThecanDismissFromPointerguard added by Polish web context menu fallback and sidebar icon actions #3025 lives incontextMenuFallback.ts, the browser-only fallback, so it could never fix the desktop bug.contextmenuon right-button press (Windows fires it on release). So the native menu pops up — positioned directly under the cursor — while the button is still physically held. The menu takes the pointer grab, and the tail of the same right-click gesture (the button release) lands on whatever item happens to sit under the cursor and activates it. This also explains the reported workaround: holding the right button and dragging away before releasing means the release lands outside the menu.Change
In the desktop preload,
desktopBridge.showContextMenunow waits (Linux only) for the pointer buttons to be released before invoking the context-menu IPC — i.e. the menu opens on release, exactly matching the Windows event semantics that don't exhibit the bug. Button state is tracked with capture-phase pointer listeners;pointercanceland windowblursettle the wait so it can't hang. Menus opened with no button held (keyboard, normal-click "…" buttons — whereclickfires after release) are unaffected, as are Windows and macOS entirely.The
process.platformcheck uses the repo's establishedoxlint-disablepattern for standalone non-Effect scripts (same asapps/desktop/scripts/*).Verification
vp checkandvp run typecheckpass.🤖 Generated with Claude Code
Note
Low Risk
Linux-only behavior in the desktop preload around context menu timing; no auth, data, or shared API contract changes.
Overview
Fixes #3698: on Linux, sidebar right-click context menus could open and immediately dismiss while a random item activated.
The desktop preload now gates context menu IPC on Linux only. It tracks pointer button state with capture-phase
pointerdown/pointeruplisteners (pluspointercanceland windowblurso waits can't hang), andshowContextMenuawaits pointer release before invoking the native menu—matching Windows-style open-on-release and avoiding the menu grabbing the pointer while the button is still down.Keyboard and click-opened menus (no button held) and Windows/macOS are unchanged.
Reviewed by Cursor Bugbot for commit 94840df. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Fix Linux context menus from activating an item on open
On Linux, right-clicking to open a context menu could immediately activate the item under the cursor because the mousedown event fired before the menu appeared. This fix defers the IPC call that opens the context menu until all pointer buttons are released.
pointerButtonsHeldcounter in preload.ts updated by globalpointerdown,pointerup,pointercancel, andblurlisteners.waitForPointerReleaseutility that resolves immediately when no buttons are held, or waits for the nextpointerup/pointercancel/blurwith zero buttons pressed.desktopBridge.showContextMenunow awaitswaitForPointerReleaseon Linux before invoking theCONTEXT_MENU_CHANNELIPC; behavior on macOS and Windows is unchanged.📊 Macroscope summarized 94840df. 1 file reviewed, 0 issues evaluated, 0 issues filtered, 0 comments posted
🗂️ Filtered Issues
No issues evaluated.