tauri: 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/128x128@2x.png",
        "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.

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 10
Comments: 21 (7 by maintainers)

Commits related to this issue

fix(macos): do not trigger unsupported key feedback sound on keypress Ref https://github.com/tauri-apps/tauri/issues/2626 — committed to tauri-apps/wry by lucasfernog 2 years ago
fix(macos): do not trigger unsupported key feedback sound on keypress (#742) Ref https://github.com/tauri-apps/tauri/issues/2626 — committed to tauri-apps/wry by lucasfernog 2 years ago

Most upvoted comments

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.

wusyong on Sep 5, 2022

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

nothingismagick on Jul 16, 2022

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?

thejawker on Aug 27, 2022

@ParthJadhav We fixed this in https://github.com/tauri-apps/tao/pull/614 It should be available in next tauri release.

wusyong on Nov 7, 2022

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? 😢

daun-io on Sep 19, 2022

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

mantou132 on Sep 15, 2022

+1, I also facing this.

OceanBelongsToMe on Jan 1, 2022

This is a regression from https://github.com/tauri-apps/tao/pull/623. I’ll look into it

wusyong on Nov 18, 2022

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.

lucasfernog on Nov 13, 2021