MacOS: Keypress on non-input element triggers unsupported key feedback sound.

[nruhe]

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:

1. Launch a Tauri window with a Webview that contains no content-editable DOM elements (i.e. no input).
2. Click the window to bring it into focus.
3. Press any key on your keyboard
4. 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.

[mszu]

+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

[KusStar]

+1, I also facing this.
It seems like tauri-apps/tao already setup functions like acceptsFirstResponder , but still have problems.

[lucasfernog]

/upstream tauri-apps/wry

[lucasfernog]

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.

[wusyong]

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.

[OceanBelongsToMe]

+1, I also facing this.

[farfromrefug]

Sorry to bump this. I understand setting the NSView as first responder did not work, but what about the addLocalMonitorForEvents solution? Did anyone try?

[schickling]

Is there any "user land" workaround available for this issue until it gets fixed?

[mantou132]

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 },
);

[nothingismagick]

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

[ghost]

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.

[thejawker]

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?

[sualehasif]

Yeah, I am also relying on the JS hack that I would not want to do long term? Hoping for an upstream push here?

[Schr3da]

Workaround does unfortunately not work for me :/

[wusyong]

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.

[daun-io]

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]

How do we implement this @amrbashir || @lucasfernog

[wusyong]

@ParthJadhav We fixed this in tauri-apps/tao#614
It should be available in next tauri release.

[ParthJadhav]

Hey @wusyong , Fixed in latest release 1.2.0 🚀

[Vehmloewff]

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"] }

[wusyong]

This is a regression from tauri-apps/tao#623. I'll look into it