Conflict priority with system-level shortcuts

What it is

The same chord may be defined by the operating system, the window manager, a browser chrome, and the app. Who actually fires depends on who consumes the event first as it travels up the focus chain. System shortcuts usually win: an app binding never reaches its handler, or the app intercepts a system chord at the wrong layer. Conflict is not two features happening to share a name. A keystream can be delivered once.

Why it happens

Key events bubble from the focused widget; any listener along the way may consume them. The OS registers application switching, lock screen, screenshots, and IME switching at an outer layer the app process never sees. A browser parks tab-close, find, and reload on the chrome, so a page that binds the same string fails silently. An app that registers through a global hotkey API may steal keys meant for another program while it is not even foreground. The symptom is a menu that prints the shortcut, a press that runs something else, or a press that does nothing. If priority is unspoken, the expert path becomes an unreliable path—the same hand shape flips meaning across hosts.

Studying it

Conflict can be traced on real hosts: bind the same chord at system, browser, and app layers and record which handler runs, plus whether the result matches the user’s expectation. Independent variables include where focus sits, whether the app is foreground, and use of global hotkeys; dependent measures include the receiving layer and whether failure is silent or a misfire. Accepting shortcuts only in a browserless test window misses the set already claimed by chrome.

Where it stops holding

User-defined system shortcuts rewrite the vendor reserve list, so avoiding “documented reserved keys” can still collide. Embedded webviews, remote desktop, and virtual machines add further event boundaries where priority flips again. Assistive technology (a screen reader’s modifier) is another outer consumer. Full-screen games that take exclusive input often keep almost every key, and system chords may then never arrive.

Applying it

• Inventory reserved chords on the target OS and browser and yield to them; if an app must take one, mark “may be intercepted by the system” in shortcut settings.
• Do not enable global hotkeys by default that steal chords while another app is foreground; make global listening an explicit option.
• Press every published shortcut on a real host (desktop + browser + app). Check the menu label, who actually fires, and whether failures explain themselves—not only whether a standalone window handles the chord.

Related

• Same group: C6.03.1 Shortcuts are an expert path, not the only path · C6.03.2 Tradeoff between mnemonic and positional assignment · C6.03.3 Shortcuts must be shown beside their menu items to support learning
• Adjacent: C6.04 Modifier keys · C6.25 IME state and switching
• Search: shortcut conflict · reserved chord · global hotkey