Closed seungwoochoe closed 1 month ago
Yep, got the same problem in rcmd. RegisterEventHotKey
seems to now return -9868
error for Option-only hotkeys, which, from what I can see in the assembly, it means something like hotKeyAlreadyExistsErr
.
At first I thought this might be related to the Input Source since it has special keys on Option-character but switching to Unicode Hex Input which does not have special characters still doesn't fix the issue.
Passing kEventHotKeyExclusive
to the options:
parameter doesn't change anything (tried it in case this might be a recent macOS bug on how this parameter is treated).
I recommend submitting a report to Apple (with Feedback Assistant).
FB14730958 reported. I have no idea what you can do with that issue ID but I'll let you know if I get any response.
No response so far and the Apple event is coming up on September 9th. I guess this is shipping as is.
Another nail in the coffin for publishing apps on the Mac App Store and staying inside the sandbox...
I'm having this same issue, but was able to work around by using CTRL as the modifier key instead of Option. That at least allows me to invoke Maccy's clipboard.
However, after changing the default shortcut, Sequoia kept giving me a permissions warning that Maccy needed access to Accessibility Settings every time I used the new shortcut combo. I couldn't actually paste anything from Maccy's clipboard.
Maccy was already configured to have the right permissions in the Accessibility permissions pane in Settings, and adding/removing Maccy from the list had no effect. Rebooting seems to have fixed it. Sucks that I have a couple of years of muscle memory to overcome, but at least the app seems functional now.
@alin23 Did you get any response from Apple recently? This "feature" has already been released. 😭
The only thing I can do in my app is tell the user to change the shortcut to Control+xxx now.
@alin23 Did you get any response from Apple recently? This "feature" has already been released. 😭
Nope, no response whatsoever. I'm trying to find a workaround for this in rcmd as we speak because I'm drowning in support emails at the moment.
I also don't have any good solution other than disallowing Option and Option+Shift.
I have submitted a report to Apple: https://github.com/feedback-assistant/reports/issues/552
I recommend everyone here do the same. Feel free to simply duplicate my report. The more reports, the more likely Apple will do something about it.
Looks like we have our answer: https://developer.apple.com/forums//thread/763878?src=push&answerId=804374022#804374022
Frameworks Engineer Apple
This was an intentional change in macOS Sequoia to limit the ability of key-logging malware to observe keys in other applications. The issue of concern was that shift+option can be used to generate alternate characters in passwords, such as Ø (shift-option-O).
There is no workaround; macOS Sequoia now requires that a hotkey registration use at least one modifier that is not shift or option.
That's so sad. Maybe we need to implement something in this library to prompt the user to change the shortcut if it’s blocked by macOS 15.
It's interesting/weird that they even seem to differentiate between sandboxed and non-sandboxed apps for RegisterEventHotKey. My BetterSnapTool app also uses RegisterEventHotKey, but option-only hotkeys still seem to work fine because it's not sandboxed. Or maybe it's because of the Accessibility permissions? Have you checked whether your apps still work correctly if you add them manually to the Accessibility section in System Settings => Privacy & Security?
(If adding to Accessibility helps, I don't think there is a rule in the App Store about telling the users to add the app there)
It's interesting/weird that they even seem to differentiate between sandboxed and non-sandboxed apps for RegisterEventHotKey. My BetterSnapTool app also uses RegisterEventHotKey, but option-only hotkeys still seem to work fine because it's not sandboxed. Or maybe it's because of the Accessibility permissions? Have you checked whether your apps still work correctly if you add them manually to the Accessibility section in System Settings => Privacy & Security?
(If adding to Accessibility helps, I don't think there is a rule in the App Store about telling the users to add the app there)
Accessibility Permissions don't seem to help. The sandbox is the differentiating factor here, which rules out all App Store apps.
It's interesting/weird that they even seem to differentiate between sandboxed and non-sandboxed apps for RegisterEventHotKey. My BetterSnapTool app also uses RegisterEventHotKey, but option-only hotkeys still seem to work fine because it's not sandboxed. Or maybe it's because of the Accessibility permissions? Have you checked whether your apps still work correctly if you add them manually to the Accessibility section in System Settings => Privacy & Security? (If adding to Accessibility helps, I don't think there is a rule in the App Store about telling the users to add the app there)
Accessibility Permissions don't seem to help. The sandbox is the differentiating factor here, which rules out all App Store apps.
Would you consider releasing a version that's not sandboxed? As it is, having to use a second key such as Ctrl makes this much less useful. At this point Alt Tab becomes more convenient.
It's not possible to do that on the App Store. I will have to put in the work to implement licensing and payments and all that other stuff to publish rcmd outside of the App Store. I will probably do it sometimes in the near future.
In any case, this is off topic for this thread, but I thought I should at least answer your question.
Just FYI: even outside the sandbox apps are limited in what they can do using the standard APIs. While secure input mode is active even non-sandboxed apps can not make use of shortcuts that consist of single keys, opt+key or shift+opt+key anymore.
There are ways around that using IOKit, but the situation is pretty absurd - especially because none of this seem to be documented.
Just FYI: even outside the sandbox apps are limited in what they can do using the standard APIs. While secure input mode is active even non-sandboxed apps can not make use of shortcuts that consist of single keys, opt+key or shift+opt+key anymore.
There are ways around that using IOKit, but the situation is pretty absurd - especially because none of this seem to be documented.
Damn, they really went all in on this "security" thing. I guess NSEvent.addGlobalMonitorForEvents
is the only thing remaining that's reliable enough.
NSEvent.addGlobalMonitorForEvents never worked while secure input is active though ;-( (which is understandable)
Apple says on Feedback Assistant that it has deployed a fix for this issue in macOS 15.2 Beta.
I've just updated to the most recent beta (15.2 Beta (24C5057p)) and the issue is still present.
Yeah.. I just received this message :(
I'm using this package in LaunchPalette, and option key only (plus shift) shortcuts do not work on macOS 15.0 beta.
Shortcuts that include modifiers other than the option key still work.