Problem
Right-clicking an HTTP(S) link in a chat message no longer offers Copy Link when the integrated browser is available. The same action was previously added by #1835 for #677, but the newer chat-specific menu replaces the native desktop menu with only Open in integrated browser and Open in system browser.
This makes copying a destination unnecessarily awkward and creates inconsistent behavior depending on whether preview support is active.
Root Cause Analysis
Preview-capable chat links now intercept the browser context-menu event and display a renderer-owned menu. Because the native event is suppressed, the desktop shell never gets a chance to add its existing safe-link copy action. The replacement menu recreated the two open actions but omitted the copy action.
The interception is also broader than the intended external-web-link behavior, so fragment links and non-HTTP schemes can receive browser-opening actions that do not apply to them.
TDD Fix Plan
-
RED Add a focused interaction test proving that the preview-capable HTTP(S) link menu contains Open in integrated browser, Open in system browser, and Copy Link, while canceling performs no action.
GREEN Define the complete external-link menu in one tested interaction boundary and use it from chat markdown.
-
RED Add a test proving that choosing Copy Link writes the exact destination to the clipboard without invoking either open action, and that clipboard failures are reported through the existing markdown-action error path.
GREEN Route the new action through the existing clipboard helper and error handling.
-
RED Add coverage proving that fragments and non-HTTP schemes are not intercepted by the preview-specific web-link menu.
GREEN Limit the custom menu to HTTP(S) destinations and preserve the native/default context-menu behavior for everything else.
REFACTOR Keep the native desktop fallback unchanged, centralize the renderer menu/action logic, and preserve the existing integrated-browser and system-browser behavior.
Acceptance Criteria
Problem
Right-clicking an HTTP(S) link in a chat message no longer offers Copy Link when the integrated browser is available. The same action was previously added by #1835 for #677, but the newer chat-specific menu replaces the native desktop menu with only Open in integrated browser and Open in system browser.
This makes copying a destination unnecessarily awkward and creates inconsistent behavior depending on whether preview support is active.
Root Cause Analysis
Preview-capable chat links now intercept the browser context-menu event and display a renderer-owned menu. Because the native event is suppressed, the desktop shell never gets a chance to add its existing safe-link copy action. The replacement menu recreated the two open actions but omitted the copy action.
The interception is also broader than the intended external-web-link behavior, so fragment links and non-HTTP schemes can receive browser-opening actions that do not apply to them.
TDD Fix Plan
RED Add a focused interaction test proving that the preview-capable HTTP(S) link menu contains Open in integrated browser, Open in system browser, and Copy Link, while canceling performs no action.
GREEN Define the complete external-link menu in one tested interaction boundary and use it from chat markdown.
RED Add a test proving that choosing Copy Link writes the exact destination to the clipboard without invoking either open action, and that clipboard failures are reported through the existing markdown-action error path.
GREEN Route the new action through the existing clipboard helper and error handling.
RED Add coverage proving that fragments and non-HTTP schemes are not intercepted by the preview-specific web-link menu.
GREEN Limit the custom menu to HTTP(S) destinations and preserve the native/default context-menu behavior for everything else.
REFACTOR Keep the native desktop fallback unchanged, centralize the renderer menu/action logic, and preserve the existing integrated-browser and system-browser behavior.
Acceptance Criteria