Calling setIgnoreMenuShortcuts(false) during macOS window blur can crash the main process

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a matching bug report without success.

Electron Version

44.2.0

What operating system(s) are you using?

macOS

Operating System Version

macOS 26.5.2 (25F84)

What arch are you using?

arm64 (Apple Silicon)

Last Known Working Electron version

Unknown. Older versions of the application did not execute this API call during the same window-blur path.

Does the issue also appear in Chromium / Google Chrome?

No. webContents.setIgnoreMenuShortcuts() is an Electron-specific API.

Expected Behavior

Calling webContents.setIgnoreMenuShortcuts(false) while a BrowserWindow is losing focus should update the shortcut state safely, or have no effect when shortcuts are already enabled. The Electron main process should remain running.

Actual Behavior

The Electron main process intermittently terminates with EXC_BAD_ACCESS (SIGSEGV) during a macOS window-focus transition.

The crash was observed repeatedly when browser-window-blur synchronously caused setIgnoreMenuShortcuts(false) to be called for multiple webContents instances, including BrowserWindow, WebContentsView, and detached DevTools contents.

After a crash, macOS window-state restoration can immediately restore the same window arrangement and cause a crash loop on subsequent development launches.

Seven same-signature crashes were recorded with Electron 44.2.0 during one investigation session. A matching crash was also observed with Electron 43.4.1.

Testcase Gist URL

A standalone testcase is not currently available. An attempted reduced example using two BrowserWindows, a WebContentsView, detached DevTools, and automatic focus changes did not reproduce the crash reliably.

Additional Information

Adding an application-side state guard stopped the crash: setIgnoreMenuShortcuts(false) is now called only if a shortcut hold was actually active. Ordinary window blur events no longer perform an idempotent native reset, and the guarded behavior has automated regression coverage.

On macOS, launching the development application once with -ApplePersistenceIgnoreState YES bypassed the window-state restoration loop. This is only a recovery measure.

Issue #53808 also concerns a WebContentsView native crash, but has a different trigger: it passes an extension background page into new WebContentsView({ webContents }) and crashes while applying web preferences. This report concerns setIgnoreMenuShortcuts(false) during an AppKit focus transition.

Sanitized crash summary:

Application: Electron
Electron version: 44.2.0
Operating system: macOS 26.5.2 (25F84)
Architecture: arm64
Translated: No

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000110
Termination Reason: SIGNAL 11, Segmentation fault
Faulting Thread: CrBrowserMain
Dispatch Queue: com.apple.main-thread

Relevant partially symbolicated frames:

-[NSWindow _realMakeFirstResponder:] + 196
-[NSView _setHidden:setNeedsDisplay:] + 280

The application originally attached a reset callback for every webContents created, including BrowserWindow renderers, WebContentsViews, and detached DevTools:

app.on("web-contents-created", (_event, contents) => {
  const reset = () => {
    if (!contents.isDestroyed()) {
      contents.setIgnoreMenuShortcuts(false);
    }
  };

  app.on("browser-window-blur", reset);
  contents.once("destroyed", () => {
    app.removeListener("browser-window-blur", reset);
  });
});

Consequently, one browser-window-blur event could synchronously update several native views while AppKit was changing the first responder.

The application-side mitigation avoids the native call unless the state was previously enabled:

const reset = () => {
  if (!held) return;

  held = undefined;
  if (!contents.isDestroyed()) {
    contents.setIgnoreMenuShortcuts(false);
  }
};

The correlation with setIgnoreMenuShortcuts(false) and the effectiveness of the state guard are strong, but a standalone testcase has not yet reproduced the failure reliably. The surrounding Electron frames were not symbolicated reliably enough to identify a specific Electron source location.