Apple Intelligence is now available on iPhone, iPad, and Mac!
In text input fields, pressing Command-Option-Any Arrow (up/down/left/right) produces a ”bonk” sound. It makes it quite annoying working with text editors that utilizes these keyboard shortcuts.
MacBook Pro 15", macOS 10.14
I'll include the, so far, only known workaround here, in case someone misses the link:
{
"@\UF701" = "noop";
"@\UF702" = "noop";
"@\UF703" = "noop";
}
Then restart Atom, VS Code, Safari, Chrome, FireFox, LightTable, or whatever app you have the bonk problem in.
I'll include the, so far, only known workaround here, in case someone misses the link:
{
"@\UF701" = "noop";
"@\UF702" = "noop";
"@\UF703" = "noop";
}
Then restart Atom, VS Code, Safari, Chrome, FireFox, LightTable, or whatever app you have the bonk problem in.
So, here is a repro:
Again, you are not helping.
It is a problem in any application that binds those keys to something. They might be able to work around the problem in Chromium and thus help all Electron apps, but that would still just be a workaround. You'd still get the bonk using Safari for a web based text editor binding those keys, for instance.
Here's an indication that it is a MacOS problem. A way to temporarily get around this is to shut down VS Code or Atom or whatever editor you have the bonk problem in, then go to System Preferences and assign the keyboard shortcut to something, then deselect that shortcut, then start your editor again.
Correction. I was pressing Command Option Arrow. Control Option Arrow does bonk. It bonks because as we keep saying, it's an invalid Mac shortcut but not in the editor. You would have to send feedback to those folks. It is not an Apple editor.
No one has asked for an explanation for the bonk. Only for a way to make it stop. Or even it is that I know how to make it stop, but would like to be able to instruct my users that does not involve creating a file at a certain place with some certain content.
If you do not feel you are in a helpful mode, dialbrain, you always have the option to just don't engage when someone asks for help.
As a user of a web-based text editor (Atom), this issue has plagued me for ages. I initially thought the issue was with Chromium (which Atom uses) but seeing the issue also occur in CodeSandbox in Safari makes it seem like it’s a deeper, perhaps OS-level problem. 🤔
dialabrain, suggesting that we mute audio or disable sound effects isn’t helpful, as that’s clearly not what cobpez is asking. We are trying to understand why the sound is happening, figure out a real solution, and/or get confirmation this is a bug in the OS.
Is there something I can do to better help you understand the problem? Or something you can do to better help me understand why you think it’s not a problem?
You keep on rudely suggesting that we contact Brackets, VSCode, and Atom to have them fix the issue, as you don’t think it’s an issue with the OS. That’s understandable, as Chromium is a custom, native app, so there’s almost certainly something Chromium could do to fix (or workaround) the issue.
However, the issue also occurs in CodeSandbox in Safari. Is there something you think CodeSandbox could do in JavaScript to fix the issue? If so, what?
If not, are you saying Safari itself has a bug in it? If not, that seems to indicate that the issue might be in the OS.
The javascript would have to capture the modifier key combination and let the browser know it can handle it. It appears it is registering the sequence, but not telling the browser. The browser can't do anything with it so it punts to the OS. The OS has no registered shortcut so it plays the error tone.
I have no idea whether the javascript framework can process such a thing, but that's what I see happening based on your description. It appears the text window isn't consuming the modifier key sequence passed to it. It appears to be responding correctly to the command, but it isn't telling the browser that it can handle the sequence.
+1 Personally I agree and think continuing to rehash the fact the text editors in question are the issue seems to fall on deaf ears. I for one don't believe this is an Atom or CodeSandbox support forum. I do wish everyone luck.
Thanks! Logically that makes sense, but I’ve looked through the source code for Atom and as far as I can tell it does properly intercept the event and tell the browser not to handle it. Here’s a link on the off-chance someone else wants to peruse it (it’s written in CoffeeScript).
https://github.com/atom/atom-keymap/blob/22252d7ca52713cf9c3b93c99f97a7136e505b0f/src/keymap-manager.coffee
Also, while I could certainly imagine one of the editors failing to properly handle keyboard events, it does seem a bit unlikely that after several years of existence, four widely-used editors would all have the exact same problem…
This is interesting. Do you (or does) happen to know why this works? Is this effectively the same as opening System Preferences -> Keyboard -> Shortcuts and setting a shortcut for Ctrl+Command+Left/Down/Right? The difference being that the preferences UI doesn’t actually allow you to set a “noop” and do nothing with the shortcut?
I think that registering those shortcuts in System Preferences only works temporarily. But, yes, it is the same basic mechanism. The system bonks on shortcuts that it thinks does not have a binding, even if they are bound by whatever mechanism that javascript binds them. Giving them a default system binding to nothing at all stops the bonking while allowing apps to rebind them.
My bug report was just closed as a dupe.
Unfortunately the way the system is designed I can’t actually see the title or description of the duplicate, or see the discussion that’s been had, but the fact that the “original” report is open seems to indicate that this is actually an issue with the OS. Presumably they would have closed it if they didn’t think it was an actual issue.
Is there a way to stop the Mac from making a bonk sound when you press Control-Command-Any Arrow Key?
