fix(amazonq): enable external links to open in system browser #6142
Conversation
aseemxs
force-pushed
the
fix/broken-links
branch
from
b939430 to
a38f525
Compare
Links in chat responses were not opening because: 1. Link URL was being read from wrong JSON path (node.link instead of node.params.link) 2. Was delegating to LSP server which has empty handlers Now opens browser directly on client side with correct URL extraction.
link.foreground returns black in some themes, use 'link' key instead which has the correct blue color
aseemxs
force-pushed
the
fix/broken-links
branch
from
a38f525 to
7ad3844
Compare
There was a problem hiding this comment.
The theme change is intentional - it fixes link styling to make them properly blue/visible. The old lookup was failing to find the right color, so links weren't visually distinguishable. This is part of the overall "fix links" scope since broken styling affects link usability.
...s-community/src/software/aws/toolkits/jetbrains/services/amazonq/webview/BrowserConnector.kt
Outdated
Show resolved
Hide resolved
| } | ||
|
|
||
| CHAT_LINK_CLICK -> { | ||
| handleChat(AmazonQChatServer.linkClick, node) |
There was a problem hiding this comment.
are there implications to telemetry
There was a problem hiding this comment.
No telemetry impact. Telemetry is sent from the UI side (chat-client) before it reaches BrowserConnector:
// messager.ts
onLinkClick = (params: LinkClickParams): void => {
this.chatApi.linkClick(params) // → aws/chat/linkClick (what we handle)
this.chatApi.telemetry({ ... }) // → telemetry/event (sent separately)
}
The old handleChat(AmazonQChatServer.linkClick, node) forwarded to the LSP server which has empty handlers (onLinkClick() {}). It wasn't contributing to telemetry - just a dead end that never opened the browser.
- Open browser directly when link click messages are received - Support both Flare (aws/chat/linkClick) and legacy (response-body-link-click) message formats - Fix link color by using correct theme key lookup - Add constants for legacy link click message types
| CHAT_LINK_CLICK, RESPONSE_BODY_LINK_CLICK -> { | ||
| node.get("params")?.get("link")?.asText()?.let { BrowserUtil.browse(it) } | ||
| } | ||
|
|
||
| CHAT_INFO_LINK_CLICK -> { | ||
| handleChat(AmazonQChatServer.infoLinkClick, node) | ||
| CHAT_INFO_LINK_CLICK, FOOTER_INFO_LINK_CLICK -> { | ||
| node.get("params")?.get("link")?.asText()?.let { BrowserUtil.browse(it) } | ||
| } | ||
|
|
||
| CHAT_SOURCE_LINK_CLICK -> { | ||
| handleChat(AmazonQChatServer.sourceLinkClick, node) | ||
| CHAT_SOURCE_LINK_CLICK, SOURCE_LINK_CLICK -> { | ||
| node.get("params")?.get("link")?.asText()?.let { BrowserUtil.browse(it) } |
There was a problem hiding this comment.
i think it is ridiculous that we have 6 different messages, all with the same payload format, that ask the client to open a browser link
There was a problem hiding this comment.
@rli Agreed on the 6 message types being excessive. Should I create a follow-up issue to consolidate these into a single OPEN_LINK message type?
There was a problem hiding this comment.
i think the bigger question is where these new messages came from because i dont see a reference to them outside of vsc/jb
There was a problem hiding this comment.
These UI message types (source-link-click, response-body-link-click, footer-info-link-click) were originally created in VSCode and then ported to JetBrains, creating the same architectural redundancy in both codebases.
There was a problem hiding this comment.
if these are needed, why don't eclipse and VS have references to this?
There was a problem hiding this comment.
Eclipse uses a single PluginUtils.handleExternalLinkClick() method that directly calls the platform's browser API. No message types needed - just openURL(new URL(url)).
- Move FOOTER_INFO_LINK_CLICK, RESPONSE_BODY_LINK_CLICK, SOURCE_LINK_CLICK from FlareChatCommands.kt to ChatConstants.kt - These constants don't follow aws/chat/ prefix pattern and belong with other chat constants - Update BrowserConnector.kt imports to use ChatConstants
- Move FOOTER_INFO_LINK_CLICK, RESPONSE_BODY_LINK_CLICK, SOURCE_LINK_CLICK from FlareChatCommands.kt to ChatConstants.kt - These constants don't follow aws/chat/ prefix pattern and belong with other chat constants - Update BrowserConnector.kt imports to use ChatConstants
…lkit-jetbrains into fix/broken-links
- Change Rider sdkVersion from '2025.3-SNAPSHOT' to '2025.3' - Resolves CI dependency resolution failures
This reverts commit e8b12e6.
2 participants
Types of changes
Description
Problem:
External links in Amazon Q chat responses and footer (e.g., in /help command responses) were not opening when clicked in JetBrains IDEs.
Root Cause:
The existing link click handlers (
CHAT_LINK_CLICK,CHAT_INFO_LINK_CLICK,CHAT_SOURCE_LINK_CLICK) were broken due to two issues:node.params.linkon the client sidelink.foregroundtheme key which resolves to black in some themesFix:
node.params.linkBrowserUtil.browse()instead of delegating to LSP serverresponse-body-link-click,footer-info-link-click,source-link-click)linkinstead oflink.foreground) so links display in proper blue coloracross all themes
Screen.Recording.2025-12-11.at.1.14.26.PM.mov
Impact:
Checklist
CHANGELOG if the change is customer-facing
in the IDE.
License
I confirm that my contribution is made under the terms of the Apache 2.0 license.