From c576d71b5c50b92bdbe796da36cfa2f59424e801 Mon Sep 17 00:00:00 2001 From: Tyler Hebenstreit Date: Mon, 11 May 2026 09:34:59 -0500 Subject: [PATCH] Fix stale isLoopOpen check causing action keys to leak to focused app In KeybindTrigger.performKeybind, the normal (non-bypassed) keybind branch returned a consume/opening decision based on the isLoopOpen value captured at the top of the function, *before* the openLoop() call on the preceding line had a chance to update Loop's state. When the trigger key and action key are pressed in rapid succession, this loses the race and returns .opening, which forwards the action key to the frontmost app. The bypassed-action branch 16 lines below already uses the fresh checkIfLoopOpen() for the same return decision. The inline comment on lines 193-194 documents the intent ("Only consume the event if the last command actually opened Loop") which the fresh check honors and the stale check contradicts. --- Loop/Core/Observers/KeybindTrigger.swift | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Loop/Core/Observers/KeybindTrigger.swift b/Loop/Core/Observers/KeybindTrigger.swift index ef28fecf..4bfb129f 100644 --- a/Loop/Core/Observers/KeybindTrigger.swift +++ b/Loop/Core/Observers/KeybindTrigger.swift @@ -192,7 +192,7 @@ final class KeybindTrigger { // Only consume the event if the last command actually opened Loop. // The main reason Loop *wouldn't* open after an `openLoop` call would be because the user has enabled a trigger delay. - return isLoopOpen ? .consume : .opening + return checkIfLoopOpen() ? .consume : .opening } // Only trigger Loop without an action if the only pressed keys perfectly matches the trigger key.