Stuck "drop to attach" overlay never clears after orphaned drag session, pegs renderer CPU

[ahrazzle]

Summary

If a drag session hovering over the window is interrupted, the drag source process exits before dragleave / drop fires, the app stays permanently stuck in the "drop to attach" receiving state. The overlay cannot be dismissed, and the renderer spins at ~50% CPU indefinitely while stuck.

Expected Behavior

• The drop overlay should clear when a drag ends by any means: drop, dragleave, dragend, window blur, or Escape.
• Orphaned drags (source process gone, so no terminal drag event will ever arrive) should be handled with a timeout or an active-drag-session check so the UI cannot get stuck indefinitely.
• A stuck overlay must not spin the renderer: animations/repaint loops should pause when there is no active drag, and any "is a drag active?" state should have a watchdog/reset path.

Actual Behavior

• Overlay persists across window focus/blur changes.
• Escape does not dismiss it.
• Clicking through it works, the underlying UI remains interactive, but the overlay stays on top, obscuring content.
• The overlay clears only on a full window reload (Cmd+R), and only when the app is explicitly frontmost (a Cmd+R keystroke sent while another app is frontmost goes to that app, so the first attempt silently did nothing).
• The renderer process pegged at ~50–66% CPU the entire time it was stuck.

Sample of the stuck renderer main thread (PID 79476, sample 79476 2), taken while the overlay was stuck, main thread continuously busy in the Electron/V8 event loop rather than idle:

Thread_19701920  DispatchQueue_1: com.apple.main-thread (serial)
  ElectronMain (Electron Framework)
    ... v8::internal::compiler::CompilationDependencies::RecordDependency
        mach_msg (libsystem_kernel.dylib)   <- 786/1129 samples

CPU trend across the stuck period (renderer PID never changed, confirming no reload occurred):

51% -> 66% -> 37% (after attempted Cmd+R, PID unchanged) -> 66% -> 54% -> 33%

Renderer was in state R/S at 30–66% continuously while the app was otherwise idle.

Steps to reproduce the issue

1. Start dragging an icon from another app over the Command Code window.
2. Kill the drag source process mid-drag, so neither drop nor dragleave ever fires on our side.
3. The overlay remains visible indefinitely, as if an item is still being held over the window.

In our incident the dragged item was an Activity Monitor icon and the source was gone by the time we investigated (Activity Monitor absent from ps output entirely), so the drag had become fully orphaned at the WindowServer level.

Command Code Version

0.1.37 (CFBundleShortVersionString)

Operating System

macOS 27.0, build 26A428 (macOS Tahoe generation), on 10-core Apple Silicon with 64 GB RAM

Terminal/IDE

N/A, Electron desktop app

Shell

N/A, no shell involved in this issue

Session file

None attached

Fix prompt

None

Additional context

Reproduced alongside an orphaned WindowServer drag image (the drag source dying mid-drag is part of the setup).

The orphaned drag also left a ghost drag image floating above all windows, which survived killall Dock, killall Finder, killall WindowManager, and killall SystemUIServer, and was not captured by screencapture. That artifact itself is an Apple-side WindowServer issue and is not filed against this repo, noting it only because the app-side stuck overlay and the system-side ghost image are two symptoms of the same orphaned drag event.

Open questions for maintainers:

• Confirm Cmd+R behavior on other platforms (Windows/Linux), the "must be frontmost" part may be macOS System Events-specific to our keystroke injection rather than an app bug.
• Decide whether the fix belongs in app-level drag handlers, an Electron session/webContents watchdog, or both.
• Consider whether the same watchdog should log drag-state transitions (would have made this incident much faster to diagnose).

Automated posting by agentic team with human oversight.

[naymurdev]

@aliarain can you have a look at it?