🐞 Command (⌘) + arrow keys unexpectedly trigger loop

[misaka]

Bug Description

The Command (⌘) + arrow keys are triggering Loop when it shouldn't. My trigger key is set to Left-Command + Left-Fn keys. Those keys continue to work as expected, however, when I hit Command-Up this also triggers Loop. This has only started happening in the last week or so.

• Either Command key triggers Loop.
• So far as I can tell it only happen when Command + Fn are used as a trigger, I've tried Command + Alt, Command + Shift, Command + Control.
• Loop only triggers when I hit Command + Up/Down/Left/Right/PgUp/PgDn/Home/End, but not other keys (letters, numbers).

Steps To Reproduce

1. Configure the trigger key to be Left-Command + Left-Fn.
2. Press Command-Up. (does not require an action to be bound to that keystroke)

Expected Behavior

The Command key(s), on their own, should not trigger Loop as configured.

Actual Behavior

The Command key(s) trigger Loop.

Screenshots

No response

macOS Version

15.5

Loop Version

Version 🧪 1.4.0 (1541)

Additional Context

No response

Final Checks

• My issue is written in English
• My issue title is descriptive
• This is a single bug (multiple bugs should be reported individually)
• I can help with fixing or developing this issue (tick if you can help).

[mrkai77]

This is definitely not intended behavior, but I was able to reproduce it on my side. Will look into potential causes!

[misaka]

Thanks for the response @mrkai77. Just checking if this has got any further traction, or whether there's anything I can do to help. This bites me on a daily basis so ... ya, would be lovely to have a fix! 😄

[mrkai77]

Hey @misaka, sorry I haven’t been able to fix this yet. I did, however, identify the root cause :)

Modifier keys like Command, Option, and Function etc. are included in a property of key events called "modifier flags." When you press the arrow keys together with the Command key, the system also sends the Function modifier flag for some reason, and unfortunately, there doesn’t seem to be a way around this at the moment.

This may have worked correctly in the past because we previously used a CGEventMonitor to track keys, whereas the newer development versions now use an NSEventMonitor. Reverting back to CGEventMonitor would be a straightforward fix, but it comes with two main drawbacks (which is why it’s not really worth doing):

• CGEventMonitor receives key events before any key remappers, such as Karabiner Elements or Hyperkey, preventing the user's own customized keybinds from working (if any).
• CGEventMonitor can also manipulate and block system events as needed. While Loop still uses this when active, it doesn’t make sense to do so when deactivated since there’s no need to alter system events. More importantly, if there’s any memory leak or bug, it could potentially lag the entire system, where NSEventMonitor wouldn't have the ability to modify system behavior in the same way.

This bug is specifically tied to the new Loop feature that lets you press all the trigger keys and keybinds at once (generally using a key remapper). Because of this, Loop can’t reliably tell if the Function key was intentionally pressed, or sent via another key such as the arrow keys, so it sometimes activates when it shouldn’t.

I definitely plan to resolve this before the next major release, but it might take me some time to explore all the possible solutions :(

[matthiggins]

Chiming in here that I have seen the same issues and am looking forward to a fix.

I use command + option + arrow keys.

Thanks for your efforts in this.

[misaka]

This does sound like a tricky one to fix, potentially limited by macOS. I've adapted by adding CTRL to the mix, luckily that seems to be manageable for my muscle memory.

[zenangst]

Hey @misaka, sorry I haven’t been able to fix this yet. I did, however, identify the root cause :)

Modifier keys like Command, Option, and Function etc. are included in a property of key events called "modifier flags." When you press the arrow keys together with the Command key, the system also sends the Function modifier flag for some reason, and unfortunately, there doesn’t seem to be a way around this at the moment.

This may have worked correctly in the past because we previously used a CGEventMonitor to track keys, whereas the newer development versions now use an NSEventMonitor. Reverting back to CGEventMonitor would be a straightforward fix, but it comes with two main drawbacks (which is why it’s not really worth doing):

• CGEventMonitor receives key events before any key remappers, such as Karabiner Elements or Hyperkey, preventing the user's own customized keybinds from working (if any).
• CGEventMonitor can also manipulate and block system events as needed. While Loop still uses this when active, it doesn’t make sense to do so when deactivated since there’s no need to alter system events. More importantly, if there’s any memory leak or bug, it could potentially lag the entire system, where NSEventMonitor wouldn't have the ability to modify system behavior in the same way.

This bug is specifically tied to the new Loop feature that lets you press all the trigger keys and keybinds at once (generally using a key remapper). Because of this, Loop can’t reliably tell if the Function key was intentionally pressed, or sent via another key such as the arrow keys, so it sometimes activates when it shouldn’t.

I definitely plan to resolve this before the next major release, but it might take me some time to explore all the possible solutions :(

Hello everyone (long time, no talk @mrkai77 😎) 👋

I’ve worked way too much with CGEvent taps in the past, present and possibly future, so I thought I'd shared a few notes.

When creating a CFMachPort via CGEvent.tapCreate, you can choose location, placement, and options:

Location (CGEventTapLocation)

• kCGHIDEventTap: at the point HID events enter the window server.
• kCGSessionEventTap: at the point HID + remote-control events enter a login session.
• kCGAnnotatedSessionEventTap: after session events have been annotated for apps.

Placement (CGEventTapPlacement)

• kCGHeadInsertEventTap: before existing taps at that location.
• kCGTailAppendEventTap: after existing taps at that location.

Options (CGEventTapOptions)

• .defaultTap: can inspect/modify/consume events.
• .listenOnly: observe-only; cannot modify or consume events.

Using a tail-appended, listen-only tap should help to avoid Loop interfering with other applications:

let tap = CGEvent.tapCreate(
    tap: .cgAnnotatedSessionEventTap,
    place: .tailAppendEventTap,
    options: .listenOnly,
    eventsOfInterest: CGEventMask(1 << CGEventType.keyDown.rawValue) |
                      CGEventMask(1 << CGEventType.keyUp.rawValue),
    callback: { _, type, event, _ in
        // In .listenOnly, the return value is ignored, but still return the event.
        return Unmanaged.passUnretained(event)
    },
    userInfo: nil
)

With that said, there are some caveats:
1. This does not prevent other apps (with head-insert, non-listen taps) from consuming events before your tap sees them. (Don't know if that was one of the problems or not; I read it has Loop interfering being an issue.)
2. For reliability, handle tap disable/timeout and re-enable with CGEvent.tapEnable, and keep the callback fast. So events that are triggered as a consequence of a fulfilled listener should always detach themselves and perform their work outside of the current function scope, meaning that they should never run synchronously as a part of the tap.

Hope you found this useful :)

[mrkai77]

@zenangst this is actually very good and interesting information, thanks!! I'll definitely try this, the tail-appended tap might be exactly what I was looking for :)

[mrkai77]

I’ve finally implemented these changes in #849.

Special thanks to @zenangst, I spent quite a bit of time exploring the event monitoring, and it turns out that the annotated session tap was exactly what was needed. Using this new approach, Loop can now also detect left/right modifier keys much more reliably by reading the modifier flags, compared to the previous version where we mostly relied on keycodes.

The fix in this build: https://github.com/MrKai77/Loop/actions/runs/18460821804

Please let me know if you’re still experiencing the problem or if everything works as expected!

EDIT: some crashes have been resported in the version above, will update this thread once that's resolved :)

[mrkai77]

Updated build: https://github.com/MrKai77/Loop/actions/runs/18770488401 :)

[misaka]

I just tried going back to my original bindings, and it works! Nice one, thank you @mrkai77 !