[JDProfresh]

A middle click fires auxclick, never click, so the Response Viewer's click delegate never saw it and the browser followed the link's placeholder href="#", which with <base href="/"> is the dashboard root.

Problem

In the Response Viewer, and in the File Viewer's rendered markdown (which binds the same delegate), a middle click on a file path opened a new tab with the dashboard in it instead of the file. The same happened with in-document links such as [Install](#install): a new tab of the dashboard at /#install. A left click and Ctrl/Cmd+click on the same links already open the preview, the folder grid or scroll in place.

Cause

File-path links (a.rv-path) carry href="#" and in-document links href="#fragment": placeholders that _bindResponseViewerInteractions resolves itself on click. Nothing listened for auxclick, so a middle click fell through to the browser's default for the placeholder.

What it does

The two placeholder branches of the click delegate move into one local function, called from the existing click listener and from a new auxclick listener that acts on the middle button only. A middle click on a path or folder link now opens the preview or the folder grid for the same resolved path and session a click would, and a middle click on an in-document link scrolls there. Right, back and forward buttons are ignored. Real URLs (anything with a scheme, loopback ones included) keep the browser's own middle click, as before; this keeps your ask on #545 to leave middle clicks on real links to the browser, since a path link's href is a placeholder the browser cannot open. The bind stays idempotent, and the left-click path is unchanged.

Tests

test/response-viewer-middle-click.test.ts drives the shipping constants.js, app.js and terminal-ui.js in a jsdom window and dispatches real auxclick and click events:

• middle click on a relative path in a message: openFilePreview('/home/me/proj/src/app.ts', 'sess-1'), default prevented; the same for a markdown link whose destination is a path, and with Ctrl held
• a folder path: openFolderGrid with the path and session
• the File Viewer's rebased link: opens in the session the preview belongs to, not the active one
• #install: scrollIntoView on the heading, default prevented
• https:// and http://localhost:5173/ links: default not prevented, nothing called (the loopback web-tab hook included)
• right, back and forward buttons: nothing happens
• one open per gesture, a second bind adds no second listener, and a left click still opens through click
• a left click is unchanged: a path link still calls openFilePreview('/home/me/proj/src/app.ts', 'sess-1') and http://localhost:5173/ still goes to the loopback web-tab hook, both with the default prevented

Seven of the fifteen cases fail on master (default not prevented, nothing opened); the suite also goes red when the button check, the shared click path, the loopback branch, the idempotency flag or the real-URL exclusion is removed.

Verified

I checked it in headless Chromium (Playwright) on a page with <base href="/"> loading the shipping constants.js and app.js, before and after:

Middle click on	Before	After
a file path	new tab at /#	preview opens, no new tab
#install	new tab at /#install	no new tab
https://example.com/	new tab	new tab (unchanged)

Right click and left click behaved the same before and after. I have not run it against a full Codeman instance, or in Firefox or Safari.

[Ark0N]

Thanks @JDProfresh, this is a clean fix. A middle click on a file path or an in-document link in the Response Viewer (and in the File Viewer's rendered markdown) no longer opens the dashboard root in a new tab: it now does what a left click does, while real URLs keep the browser's own middle click.

I reproduced the bug on master in headless Chromium (new tabs at /# and /#install) and confirmed the fix on your branch, and your new test fails on master's app.js in exactly the seven cases you listed. Keeping the change inside the one idempotent _bindResponseViewerInteractions delegate, so the File Viewer picks it up with no second handler, is the right shape, and the cases for https:// and loopback URLs being left alone are exactly what I wanted after #545.

Nothing to change on your side. This is ready to merge.

[Ark0N]

Merged in 1.47.0 (https://github.com/Ark0N/Codeman/releases/tag/codeman%401.47.0). Thank you, nothing needed changing.

#716 (issue, hedburgaren): closed by #726 via "Fixes #716". If it stays open, comment:

Fixed in 1.47.0 (https://github.com/Ark0N/Codeman/releases/tag/codeman%401.47.0) by #726 from @Hugo-DDT: a dead-key backtick on a desktop keyboard arrives once, and plain-text Ctrl+V is framed as a bracketed paste by Codeman itself, so a copied newline no longer submits after a replay. Thanks for the clear report.