fix(amazonq): use https as scheme for local webview resource resolver #5489
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
https://developer.mozilla.org/en-US/docs/Web/API/Clipboard `navigator.clipboard` is only accessible from a "secure context", which JCEF does not think we are using, because the URI authority is not localhost or https. Since we are hooking onto the CEF resource request handler, it does not matter what we use for the scheme/authority as long as there is no conflict with real resources. Previous implementation used a different load mechanism which somehow met the secure context criteria.
samgst-amazon
approved these changes
Mar 20, 2025
Qodana Community for JVMIt seems all right 👌 No new problems were found according to the checks applied 💡 Qodana analysis was run in the pull request mode: only the changed files were checked Contact Qodana teamContact us at [email protected]
|
rli
added a commit
that referenced
this pull request
Sep 3, 2025
* feat(amazonq): Add support for Amazon Q chat on remote 242+ (#4825) * fix(amazonq): Bug Fix for "Q: Send to Prompt" doesn't work in split panes on local or remote (#5463) * fix(amazonq): use https as scheme for local webview resource resolver (#5489) https://developer.mozilla.org/en-US/docs/Web/API/Clipboard `navigator.clipboard` is only accessible from a "secure context", which JCEF does not think we are using, because the URI authority is not localhost or https. Since we are hooking onto the CEF resource request handler, it does not matter what we use for the scheme/authority as long as there is no conflict with real resources. Previous implementation used a different load mechanism which somehow met the secure context criteria. * fix(amazonq): fix agentic asset loading in remote mode (#5734) local uris cannot be loaded if the host is deemed non-remote * fix(amazonq): fix code issues tab not appearing in remote (#5737) on remote, each client gets its own instance of the tool window. logic needs to handle this case, otherwise it will only make changes against the 'main' IDE, and will not be visible to remote clients * fix(amazonq): use progress bar decorator while loading q chat on remote (#5749) animated icons do not show up on remote * fix: provide loading text when chat assets are slow to load (#5973) on remote, it can take 10+ seconds for chat to be visible. additionally, delete some unneeded assets to slightly reduce load time * feat(amazonq): limit remote to amzn-internal compute (#5993) Per internal discussion, feature deemed not ready for external users due to https://youtrack.jetbrains.com/issue/IJPL-203169 * fix: delete changelog for internal feature (#6009) * feat: show message to resize on remote chat (#6007) --------- Co-authored-by: Lokesh <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://developer.mozilla.org/en-US/docs/Web/API/Clipboard
navigator.clipboardis only accessible from a "secure context", which JCEF does not think we are using, because the URI authority is not localhost or https. Since we are hooking onto the CEF resource request handler, it does not matter what we use for the scheme/authority as long as there is no conflict with real resources.Previous implementation used a different load mechanism which somehow met the secure context criteria.
License
I confirm that my contribution is made under the terms of the Apache 2.0 license.