fix(amazonq): right click options dont send context if chat not loaded

[nkomonen-amazon]

Problem:

When a user starts up VSC, hasn't opened Q chat yet, then highlights text and does a right click option like "send to prompt" THEN the whole prompt fails to make it to chat.

This is because there is a race condition between the message being sent to the webview, and the webview completed loading and ready to recieve messages.

Solution:

In the appToMessage publisher, verify that the chat is ready to recieve messages based on if the webview sent the chat ui ready message. Otherwise wait until we get it, and then send the message.

Demo

Before

Before.mov

After 

After.mov

---

• Treat all work as PUBLIC. Private feature/x branches will not be squash-merged at release time.
• Your code changes must meet the guidelines in CONTRIBUTING.md.
• License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

• This pull request modifies code in src/* but no tests were added/updated.
  • Confirm whether tests should be added or ensure the PR description explains why tests are not required.
• This pull request implements a feat or fix, so it must include a changelog entry (unless the fix is for an unreleased feature). Review the changelog guidelines.
  • Note: beta or "experiment" features that have active users should announce fixes in the changelog.
  • If this is not a feature or fix, use an appropriate type from the title guidelines. For example, telemetry-only changes should use the telemetry type.

[jpinkney-aws]

This PR is more or less what I had in mind to solve the problem!

[jpinkney-aws]

Does it make sense to encapsulate the logic for isUiReady in this class somehow? Technically, it seems like this class is meant to hold requests until the UI is ready so keeping the uiReady logic close might make more sense

[nkomonen-amazon]

Yeah this makes sense, updated

[jpinkney-aws]

Did you experiment with trying to use a buffer that keeps filling up until the chat ui is ready? Then you can just send an event when the chat UI is ready that publishes everthing in the buffer.

I.e

if (this.isChatUIReady()) {
    super.publish(event)
    return
}
buffer.push(event)

and then you'd do something like this

onChatReady(() => {
    for (const event of this.buffer) {
        super.publish(event)
    }
})

[nkomonen-amazon]

great point, updated

[jpinkney-aws]

I think its good now, just a couple more separate thoughts:

1. Does it make sense to have a seperate uiMessagePublisher or is this something that should just live in the regular MessagePublisher? I think the upside of having it in one is technically the extension side who calls getAppsToWebViewMessagePublisher also has to wait for the ui to load before their event gets sent? It might prevent a few possible bugs? (not that I can think of any concrete examples off of the top of my head)

2. Does it make sense to focus the webview if the chat isn't ready yet? Or can we open it if its not already open? I'm guessing theres logic in the send to prompt/all the other codewhisperer commands that does something to that effect but does it make sense to put all that logic in one place?

[nkomonen-amazon]

1. Yeah I was thinking about directly adding it to MessagePublisher, but since MessagePublisher is used in the opposite direction from WebviewToApp, it wasn't completely obvious. Though we can still add the new logic in but just know which scenario to use it. Any thoughts?
2. Thats a good point. I think we can probably call focusAmazonQPanel.execute(). Currently it is redundant since all the relevant calls in the fix call it before. But it will be a good fallback in future cases.

@jpinkney-aws

[nkomonen-amazon]

/runIntegrationTests