Skip to content

MacOS: Native keybindings (Cmd+P for Print, Cmd+F for Find, etc.) cannot be rebound to no-op. #13661

@Spelkington

Description

@Spelkington

Preliminary Checks

  • I have read and understood the important section above.
  • I have searched existing issues and avoided creating duplicates.
  • I am not filing an enhancement request.
  • I have checked that this issue cannot be reproduced on Mozilla Firefox.
  • I have checked that this issue can be reproduced once I removed all my Mods and Custom CSS.

What happened?

On MacOS, it seems that keyboard bindings native to NSMenu — Cmd+P for Print, Cmd+F for Find, etc., cannot be remapped to no-op. When these shortcuts are removed from their native functions in Zen Settings, they will still continue to execute their native command until remapped to another command, and cannot be no-op'd entirely.

Expected behavior

Setting a MacOS native keybinding to Not set should disable it.

Actual behavior

The binding persists until explicitly remapped onto another command.

Steps to reproduce

For example, setting Print from the default Cmd+P to Not set will still activate the print dialog, and setting Find from Cmd+F to Not Set will still bring up Find on Page.

This also seems to happen when these native bindings are remapped, via Zen, to other bindings. For example, when setting Print to something like Cmd+Shift+/, leaving Cmd+P used by no other command, both the new macro and Cmd+P will bring up the print dialog. This behavior is also confirmed for Find.

What does resolve the issue is to set the native command to another binding. For example:

  • Set Print to Not Set
  • Remap Cmd+P to another command ("Toggle Floating Sidebar", for example)
  • Cmd+P will execute the other command, and not bring up the print dialog.

Screenshots and videos

Screen.Recording.2026-05-11.at.2.17.16.PM.mov

Demonstration of the issue on MacOS. Between each rebind, Cmd+P is pressed to demonstrate what action it's mapped to at the time. The only time Cmd+P doesn't invoke Print is when it's explicitly remapped to another command.

Screen.Recording.2026-05-11.at.2.20.07.PM.mov

Additional demonstration on the same Zen build on Arch Linux, demonstrating that this is not a universal issue.

Version

1.19.12b

What platform are you seeing the problem on?

macOS - aarch64

What component is this issue related to?

Keyboard Shortcuts

Relevant log output if applicable

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Status

    Triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions