[cogwright]

On Linux, closing a tab with a middle click also pasted the last selected text (the primary selection) into the editor that had the keyboard, as irrl found.

Cause
Chromium runs Linux's middle-click paste as the default action of the middle button's mouseup, into the focused element: here the editor, since a tab click does not take focus. The tab already cancelled the press (mousedown, so Windows and Linux do not start autoscrolling) and the click (auxclick, where it closes), but not the release. Cancelling auxclick does not stop the paste; cancelling mouseup does. That is what others found too:

• obsidian-claude-sidebar#116: "Chromium runs its own middle-click paste, a paste event into the focused element, after a middle mouseup that no listener default-prevented. preventDefault on auxclick does not stop it. preventDefault on mouseup does."
• VS Code fixed its terminal's middle-click paste the same way (Fix middle click paste over text in terminal on Linux microsoft/vscode#338580).

Fix
The tab cancels the middle button's mouseup too, next to its mousedown. It is one line on the element that takes the middle button for itself, so nothing else changes:

• A middle click in the editor or the terminal still pastes there, as Linux users expect.
• The middle click still closes the tab.

Tested

• tsc and eslint pass.
• New browser test gs-tab-middle.mjs (web build) checks:
  • a middle click on a tab closes it
  • the tab's middle mouseup arrives cancelled
  • a middle click in the editor arrives as before, not cancelled

Not tested: the paste itself. It only happens on Linux with a primary selection, and this machine is a Mac. The fix rests on Chromium's behavior as quoted above.

🤖 Generated with Claude Code