Description of the new feature / enhancement

Add a Right-Click Lock module to PowerToys' Mouse utilities: a ClickLock equivalent for the secondary mouse button.

Windows has shipped ClickLock (tap-and-hold the left button, release, and the OS keeps perceiving it as held until the next tap) since Windows 2000. There is no equivalent for the right button, and no API, Group Policy, or registry knob extends it. Right-Click Lock closes that asymmetry.

Behavior mirrors ClickLock exactly, applied to RMB:

1. Hold the right button for >= a configurable threshold (default ~500 ms).
2. On physical release, the OS continues to assert right-button-down to the foreground window.
3. The next physical right-click releases the synthetic hold.

It would live alongside the existing Mouse utilities (Find My Mouse, Mouse Highlighter, Mouse Pointer Crosshairs, Mouse Jump) and is structurally smaller than any of them.

Scenario when this would be used?

• Accessibility. ClickLock exists because button-locking helps users with limited grip strength, arthritis, or RSI. That argument is symmetric: those users need the same affordance on the right button.
• Productivity. Right-button drag and long context-menu interactions benefit from the same hold-release affordance. Particularly among CAD.
• Gaming. Sustained right-click is the de-facto camera gesture across MMOs, RTS, city builders, and flight sims. Hours of statically-held RMB load the index/middle finger and cause real discomfort or strain.

Today people solve this with AutoHotkey scripts (awkward distribution, often anti-cheat-flagged) or per-game rebinds (only when a game exposes "toggle camera"). A first-party PowerToys module is the clean fix.

Supporting information

A complete, working reference implementation already exists and validates the UX and the non-obvious safety overlays a real module would need:

• Repo: https://github.com/owenpkent/windows-right-click-lock
• Full proposal: https://github.com/owenpkent/windows-right-click-lock/blob/main/docs/proposal-right-click-lock.md
• Technical white paper (state machine, crash-safety, perf): https://github.com/owenpkent/windows-right-click-lock/blob/main/docs/whitepaper.md
• Adversarial security review: https://github.com/owenpkent/windows-right-click-lock/blob/main/docs/security-review.md
• Stack: .NET 9, WH_MOUSE_LL + SendInput, ~600 LOC, BCL-only, EV-signed release.

What the reference implementation surfaces that a PowerToys module would inherit:

• Move-cancel overlay. If the cursor moves past a small dead-zone before the lock arms, treat it as a real drag and do not lock. Without this, a right-drag-select becomes a sticky lock.
• Crash/session-safe release. A locked button can strand the OS believing RMB is held after the process exits. The implementation releases on unhandled exception, process exit, app exit, thread exception, and session lock.
• Self-injection tagging (dwExtraInfo magic value) so the hook ignores its own synthetic events.

Proposed module settings (all map onto existing PowerToys patterns):

• Master enable/disable (PowerToys framework).
• Hold-duration slider (Short to Long).
• Move-cancel toggle + pixel threshold.
• Optional activation hotkey (PowerToys centralized hotkey manager).
• Per-app exclusion list (PowerToys excluded-apps pattern) so competitive games with right-button-fire mechanics can opt out.
• Group Policy enable/disable inherited from the PowerToys GPO template.

The Core layer (state machine + settings model) is UI-agnostic C# and ports into a module project largely unchanged; the hook/injection layer is functionally equivalent to what FindMyMouse already does. I am willing to do the porting and implementation work. A condensed spec is ready on request.