Secondary click

Everybody says right click, and the word is wrong often enough to matter. Every desktop system lets the buttons be swapped, which left-handed people frequently do, so the right button is not reliably the secondary one. On a trackpad the same press is a two-finger tap, on Apple hardware it is also Control and a click, and on a one-button mouse it was only ever the modifier. The vocabulary that survives all of that is primary and secondary: the primary press acts, the secondary press asks. Naming it by function rather than by hardware is also the only way to write the sentence that follows, which is that the secondary press has one job.

That job is to reveal what could be done to the thing under the pointer, and never to do any of it. A secondary press that deletes, opens, or submits anything at the moment of the press is a bug, because the whole convention rests on it being safe to press and read. It is a shortcut for people who know it is there, which means it can never be the only way to reach a command: the same actions need a visible affordance, usually a kebab or meatball menu on the row, or the interface has hidden a feature behind knowledge that most of its users do not have. Touch screens have no second button at all. The nearest gesture is a long press, which is a different term with different timing problems, and it is worth deciding deliberately rather than assuming the desktop behaviour carried over.

On the web, listen for contextmenu rather than for a pointer event with button === 2. The two are not equivalent: contextmenu also fires from the keyboard, from the Menu key and from Shift and F10, which is the accessible route to the same actions and the one most custom implementations forget. Calling preventDefault() on it replaces the browser’s own menu, and that is a real cost to weigh rather than a formality, since the reader loses open in new tab, copy, spellcheck, translation, and their extensions in one go. Replace it only over the specific elements that genuinely have contextual actions, and leave plain text, images, and links alone.

Two details make a custom menu feel native. Select the target of the press before the menu appears, so the scope of what is about to happen is visible, but do not clear an existing multiple selection if the press landed inside it, because a right click on one of five selected files is a question about all five. And place the menu at the pointer, then pull it back inside the viewport rather than let it be clipped, which is the difference between a menu that appears where the reader is looking and one that opens off the edge of the screen.