Workflow using hotkey to trigger "Browse in Alfred" handles flag changed events poorly [Fixed 4.1.1 b1171 pre-release]

[lilyball]

I have a workflow that uses a Hotkey to trigger "Browse in Alfred". I've done this instead of using the built-in support so I can restrict the hotkey to only occur in the Finder, as that's the only app I ever use this feature with and the hotkey I use conflicts with Xcode.

 

Anyway, I just discovered a problem today, which is that Alfred interprets the flag changed events for the modifiers used by the hotkey incorrectly. As near as I can tell, it's trying to detect a quick press-and-release of the shift or control modifiers to trigger the associated behavior (quicklook or showing the action panel; I have control enabled for this behavior, I don't remember if that's a default). The problem is my hotkey is ctrl-shift-\, and if the modifiers are still held down by the time Alfred shows the panel, and I release both modifiers at the same time, Alfred will trigger one of the two behaviors (quick look or showing action panel, whichever one corresponds to the modifier that got released second). I'm pretty sure what's going on is the flags changed event doesn't actually say which flags were added/removed, it just says what the current flags are, so when the first modifier is released Alfred interprets this as the addition of the second modifier, so when that gets released it triggers the action.

 

This is rather irritating because it means I need to be really quick about releasing the modifiers when I trigger the hotkey or else I get this weird behavior. Alfred could fix this by keeping track of modifiers as global state, instead of what it's apparently doing which is keeping track of them only when the action panel is open. Or if it doesn't want to track modifiers globally, it could at least track the modifiers involved in a hotkey to see when they go away. Or poll the system when the action panel opens to see what flags are currently active.

[Andrew]

@lilyball try configuring the hotkey object to wait until the modifiers have been released:

 

[lilyball]

On 7/8/2020 at 2:59 AM, Andrew said:

@lilyball try configuring the hotkey object to wait until the modifiers have been released:

 

I forgot that setting existed. It does work around my issue, but it also slows down the activation of the shortcut, which is a shame.

[deanishe]

6 hours ago, lilyball said:

I forgot that setting existed. It does work around my issue, but it also slows down the activation of the shortcut, which is a shame.

 

Have you considered changing the Hotkey to one that doesn't include ^ or ⇧? The default uses ⌥⌘, IIRC. If you only use the feature in Finder, why not delete that and re-assign it to your workflow?

Edited July 12, 2020 by deanishe

[lilyball]

9 hours ago, deanishe said:

 

Have you considered changing the Hotkey to one that doesn't include ^ or ⇧? The default uses ⌥⌘, IIRC. If you only use the feature in Finder, why not delete that and re-assign it to your workflow?

 

Now that I’m just limiting it to the Finder it’s more reasonable to do that. In general I avoid using ⌘ in global hotkeys because I don’t want to interfere with apps. Though I ended up limiting it to the Finder specifically because ⌃⇧\ was interfering with Xcode 😅 (though to be fair ⌘⌥\ would have interfered with Xcode too).

 

Though now that I think about it, why is this a hotkey at all, instead of a Service? A Service would mean not having to muck about with Copy to figure out my selection. And IIRC service hotkeys are overridden by app hotkeys, so using ⌘⌥\ as a default hotkey for the service wouldn’t conflict with anything.

[lilyball]

Also possibly worth mentioning, my workflow was actually triggering "Browse in Alfred". If I switch over to "Action in Alfred" (which matches what the built-in hotkey actually does) then this problem goes away, because the action panel doesn't seem to respond to tapping modifiers the way the browse panel does. Still, I like being able to browse.

[Andrew]

I should have this fixed in the next build.

 

Interestingly, Alfred was already attempting to defend against this scenario, but with some code which hasn't been touched for quite some time. I've updated the way it gets the current mods, and it now works as you would expect.

[Andrew]

The 4.1.1 pre-release should now handle this better, could you let me know?

[Andrew]

I've made some further changes in the 4.1.1 b1171 pre-release, @lilyball could you please update and let me know if this improves the situation?