Mitigate registerCopyBufferSpy failures

[fbricon]

Description

In some cases registerCopyBufferSpy fails to register due to

Error activating extension: Error: command 'editor.action.clipboardCopyAction' already exists"

And clicking on the "View Logs" button doesn't work because the catastrophique failure occurs before all commands are registered.

This apparently can happen if Continue is installed on both the host and a devcontainer, or when a Continue fork, such as Granite.Code, is used.

The hack used to hook into editor.action.clipboardCopyAction is pretty ugly, but an alternative solution using the Paste API doesn't work as well as the existing solution: its support is limited to text documents. You can't intercept text copied from a webview, eg. the chat view, since it's not a TextDocument.

This PR sort of mitigates the failure:

• registerCopyBufferSpy call is moved after registering commands, so view logs still works
• registerCopyBufferSpy failure is caught and a specific message is displayed, hopefully downgrading the perceived severity of the problem.
• the rest of the activation can proceed after this specific failure.

However, I'm not completely happy with it as it would still show up 100% of the time, provided the conditions stay the same. So I'm inclined to add a "Don't show again" button. It could then store a flag in the global state (without an easy way to revert it), or in the user settings (but creating such setting feels wrong). We could also decide to always fail silently and only keep a trace in the logs.

Checklist

• [] The relevant docs, if any, have been updated or created
• [] The relevant tests, if any, have been updated or created

Screenshots

Testing instructions

• Install Granite.Code
• Open Granite.Code's chat view
• Install Continue
• Restart

cc @owtaylor @allanday

[netlify[bot]]

❌ Deploy Preview for continuedev failed. Why did it fail? →

Name	Link
🔨 Latest commit	dc05bf949cb2e03df9e98cb7924e89d0f1412889
🔍 Latest deploy log	https://app.netlify.com/sites/continuedev/deploys/6811054162fbdf0008d6f92f

[fbricon]

While we're here, I think it would be reassuring to name this as something less ominous for what it is, perhaps CopyBufferService

done

[RomneyDa]

@fbricon

This apparently can happen if Continue is installed on both the host and a devcontainer, or when a Continue fork, such as Granite.Code, is used.

Interesting if you've had any other ideas on how to hook into clipboard events in a way that this won't break?

[fbricon]

A "safer" (probably), but uglier (definitely) way to track clipboard changes would be to register a function that'd poll the clipboard content every X (500?)ms. That's what https://github.com/arjun-g/electron-clipboard-extended does.

[fbricon]

In the absence of a proper clipboard eventing mechanism (https://github.com/continuedev/continue/commit/449d0b52532e1862d6b8b0eb281de80b535a3232 is too limited) I'd rather prefer a solution where the clipboard content is checked when needed, so no need to register a spy service. So core would send a request to the IDE to fetch the clipboard only when necessary. But I'm not too familiar with the clipboard usage in Continue's codebase, so this solution might have been explored and discarded already.

I need to look at https://github.com/continuedev/continue/commit/9dd6284b8e4b1dc09b704bc00d5231af9569b6bc in more details, maybe there's a way to simplify this thing after all.

[sestinj]

I made a quick update so taht the warning message isn't shown as I don't think this is critical enough to warrant that. Will merge once tests are passing!