tauri
tauri copied to clipboard
tauri-apps
MacOS: Keypress on non-input element triggers unsupported key feedback sound.
Describe the bug
When a keypress event occurs on a non-content editable DOM element, the unsupported key feedback sound.
To Reproduce
Steps to reproduce the behavior:
- Launch a Tauri window with a Webview that contains no content-editable DOM elements (i.e. no input).
- Click the window to bring it into focus.
- Press any key on your keyboard
- You should hear a light beeping sound with each keystroke.
Expected behavior
No unsupported key feedback sound effect should play.
Screenshots
Not really applicable
Platform and Versions (required):
Operating System - Mac OS, version 11.5.2 X64
Node.js environment
Node.js - 16.0.0
@tauri-apps/cli - 1.0.0-beta.10
@tauri-apps/api - 1.0.0-beta.8
Global packages
npm - 7.10.0
yarn - 1.22.10
Rust environment
rustc - 1.51.0
cargo - 1.51.0
App directory structure
/dist
/node_modules
/src-tauri
/src
App
tauri.rs - 1.0.0-beta.8
build-type - bundle
CSP - default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'
distDir - ../dist
devPath - http://localhost:9000
framework - React
bundler - Webpack
Additional context
The error can be stopped with e.preventDefault(), but this will block input interaction.
Tauri Conf:
{
"package": {
"productName": "complex",
"version": "0.1.0"
},
"build": {
"distDir": "../dist",
"devPath": "http://localhost:9000",
"beforeDevCommand": "",
"beforeBuildCommand": ""
},
"tauri": {
"bundle": {
"active": true,
"targets": "all",
"identifier": "com.tauri.dev",
"icon": [
"icons/32x32.png",
"icons/128x128.png",
"icons/[email protected]",
"icons/icon.icns",
"icons/icon.ico"
],
"resources": [],
"externalBin": [],
"copyright": "",
"category": "DeveloperTool",
"shortDescription": "",
"longDescription": "",
"deb": {
"depends": [],
"useBootstrapper": false
},
"macOS": {
"frameworks": [],
"minimumSystemVersion": "",
"useBootstrapper": false,
"exceptionDomain": "localhost",
"signingIdentity": null,
"entitlements": null
},
"windows": {
"certificateThumbprint": null,
"digestAlgorithm": "sha256",
"timestampUrl": ""
}
},
"updater": {
"active": false
},
"allowlist": {
"all": true
},
"windows": [
{
"title": "Complex",
"width": 316,
"height": 600,
"resizable": false,
"fullscreen": false,
"transparent": false,
"decorations": true
}
],
"security": {
"csp": "default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'"
}
}
}
Stack Trace
Not applicable.
+1, I'm also seeing this.
From a cursory googling, it seems like the solution involves changes to the NSWindow/NSView to allow it to become a first responder[0][1] and/or adding handling to the NSViewController for NSEvent.addLocalMonitorForEvents(matching: .keyDown) and returning nil/not calling the superclass methods[2][3].
It looks like the low-level MacOS window setup like this is actually done in this file in the tauri-apps/tao sibling repo, so it's probably worth cross-posting this issue over there.
[0]: StackOverflow Prevent 'not allowed' beep after keystroke in NSView [1]: Apple docs NSResponder [2]: StackOverflow Unwanted beep when a key is hit [3]: Someone's Gist How to handle keyDown in NSResponder
+1, I also facing this. It seems like tauri-apps/tao already setup functions like acceptsFirstResponder , but still have problems.
Will be fixed on the next release. Thanks to @KusStar for pointing me to the solution. The problem is that wry adds a new view on top of tao, and it needed the same setup.
Reopen this because we found the input will no longer work if we don't actually handle all events. One way is adding our wkwebview as subview like before, but this will bring all focus regressions back. The other way is we add all NSView methods we defined in tao, but it will be a huge task IMHO. Unless someone finds another solution, the second one is the only approach and it might not happens before 1.0 release.
Sorry to bump this. I understand setting the NSView as first responder did not work, but what about the addLocalMonitorForEvents solution? Did anyone try?
Is there any "user land" workaround available for this issue until it gets fixed?
Stop default on the JS side:
addEventListener(
'keydown',
(event) => {
if (isTauriMacApp && event.key !== 'Tab') {
const ele = event.composedPath()[0];
const isInput = ele instanceof HTMLInputElement || ele instanceof HTMLTextAreaElement;
if (!ele || !isInput || event.key === 'Escape') {
event.preventDefault();
}
}
},
{ capture: true },
);
This feels very wrong to have to fix it in JS. We should manage this in tao/wry.
Can we look into this again @lucasfernog @wusyong
Stop default on the JS side:
addEventListener('keypress', (event) => { const ele = event.composedPath()[0]; if (ele instanceof HTMLInputElement || ele instanceof HTMLAreaElement) return; event.preventDefault(); });
Worked for me.
Also running into this issue for a music player app that's tied to various keyboard events. I can somewhat hack it by using a hidden input field that catches the input, but it's fairly unreliable and would way rather have the ability to turn off the alert sound all together.
Any updates on a fix in tao/wry?
Yeah, I am also relying on the JS hack that I would not want to do long term? Hoping for an upstream push here?
I tested with winit 0.27 with addSubview and there's no sound. I think we'll resolve this together with switching back to winit.
I'm also facing the same situation. I'm implementing some keyboard shortcuts to non-editable content and I think workaround isn't working for this case? 😢
@ParthJadhav We fixed this in https://github.com/tauri-apps/tao/pull/614 It should be available in next tauri release.
I am still getting the unsupported key feedback sound.
[build-dependencies]
tauri-build = { version = "1.2.0", features = ["config-toml"] }
[dependencies]
tauri = { version = "1.2.0", features = ["fs-all", "os-all", "shell-open"] }
This is a regression from https://github.com/tauri-apps/tao/pull/623. I'll look into it