bertg Posted March 16, 2018 Share Posted March 16, 2018 * What you were doing when the issue happened Nothing special, just trying to lock the computer. * Whether you were able to replicate it a second time by performing the same action Yes, Restarting Alfred or "Clear application Cache" do not change the behaviour. Changing the command name, or requiring Confirmation does not change the behaviour. (With confirmation, the dialogue does show up) Changing the apps name, does stop the app from opening, but still does not lock the device. Changing the name back restores the unwanted behaviour. * Include any screenshots that might help us I can share a screen recording if that is desired. * Include the Alfred version & build number you are using v3.6 [903] * Include your OS X version 10.13.3 (17D102) Link to comment
Andrew Posted March 16, 2018 Share Posted March 16, 2018 @bertg From Alfred 3.6, the lock command simulates ⌃⌘Q to lock your Mac with High Sierra installed (the new macOS system wide shortcut). If you have Alfred (or another app) overriding this key combination to launch Sequel Pro, then when Alfred dispatches this combination to macOS assuming it will lock your Mac, the combo will be intercepted and diverted to whatever is overriding it. I suspect this will be what is causing the unexpected behaviour in your case Cheers, Andrew Link to comment
bertg Posted March 20, 2018 Author Share Posted March 20, 2018 @Andrew This indeed seems to be the case. It is a bit surprising that a changed keyboard shortcut changes the behaviour of Alfred. I would recommend changing it back; or giving the user feedback that the shortcut doesn't do what it says it would do. In a related question. I have no clue what or how this change came to be. Is there a way I could figure out which app/setting is doing this? The app in question has no customisable Keyboard shortcuts, so I doubt it is causing it. Or is there a way I can restore the default behaviour? Link to comment
Andrew Posted March 20, 2018 Share Posted March 20, 2018 @bertg there is no way of Alfred knowing if this behaviour has been overridden (other than if you are doing it directly within Alfred with a workflow). From High Sierra and onwards, trying to type this combo to set as a hotkey in Alfred will be intercepted by macOS and your Mac locked, so this will prevent people from accidentally setting this combo. It's likely that this combo was set on your Mac before High Sierra? As for finding what is launching this - check your Alfred workflows for a hotkey linked to a launch app. Do you also have any other keyboard or automation related 3rd party apps installed you can check? It's unlikely that I'll be changing dispatching this combo back to the old behaviour, as the pre-10.13 way of locking now causes macOS High Sierra to hang. Link to comment
bertg Posted March 20, 2018 Author Share Posted March 20, 2018 @Andrew Thanks for this info. I hadn't thought of checking the Alfred workflows. And lo-and-behold, I found it. There is a workflow that has that key-combo set. (The hotkeys.firedev.com package) So in this case Alfred could have known So yeah, i think the latest change you described Quote From Alfred 3.6, the lock command simulates ⌃⌘Q to lock your Mac let this issue bubble to the top. I've deleted the package (as I don't like key combo's anyway) and the lock functionality is working fine again. Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now