Cursor Focus Disruption During Tool Operations

[hannesrudolph]

Which version of the app are you using?

3.3.14

Which API Provider are you using?

OpenRouter

Which Model are you using?

n/a

What happened?

The cursor focus is being unintentionally redirected during certain tool operations in Roo Code:

1. When the ask_followup_question tool is used, the cursor focus automatically shifts away from the current active location (e.g., if typing in another Roo Code tab).

2. When using file modification tools (write_to_file or apply_diff), the cursor focus automatically moves to the modified document, even if the user was actively typing in the task prompt box.

This behavior disrupts the user's workflow and requires manual refocusing to continue their previous task.

Steps to reproduce

For ask_followup_question Tool:

1. Open two tabs in Roo Code (Tab A and Tab B)
2. In Tab A, start a task that will likely trigger the ask_followup_question tool
3. While Tab A's task is running, switch to Tab B and start typing in the task prompt
4. When Tab A triggers the ask_followup_question tool, observe that the cursor focus shifts away from Tab B where you were typing

For File Modification Tools:

1. Open two tabs in Roo Code (Tab A and Tab B)
2. In Tab A, start a task that will involve file modifications
3. While Tab A's task is running, switch to Tab B and start typing in the task prompt box
4. When Tab A triggers either write_to_file or apply_diff tool operation
5. Observe that the cursor focus automatically moves to the modified document in Tab A
6. Verify that the cursor is no longer in Tab B's task prompt box where you were typing

Relevant API REQUEST output

Additional context

No response

[inigohidalgo]

I am having the same issue, it is extremely disrupting. It prevents me from reading plans, making commits and any other task I need to do while I wait for the LLM to work.

[diarmidmackenzie]

I've been looking at this.

The 2 cases are going to need different fixes.

1. When the ask_followup_question tool is used, the cursor focus automatically shifts away from the current active location (e.g., if typing in another Roo Code tab).

There's 2 possible ways to fix this. One is a targetted fix to the handling of the ask_followup_question tool.

The focus switch is triggered because of the combination of the text box being enabled, and the buttons disabled when the tool completes. By changing the button handling so the buttons are explicitly not present, we can avoid the focus change.

The other approach is to completely remove the code that grabs the focus for the text box here.

Given that task completion can take a while, and the user may have navigated elsewhere in the IDE, it's not obvious to me that we ever want to grab focus back to the text window.

The useEffect code was originally added to grab focus "when feedback is required".

However it's not clear that's desirable behaviour, given the user might be in the middle of some other activity while waiting for Roo to complete its work...

As far as I can tell, none of the other tools will trigger the focus grab when they complete. This is because the focus grab only happens when textAreaDisabled and enableButtons are both false, and all the other tools set these flags to opposing values (true/false or false/true).

The one other time I can see this focus grab is triggered is when switching between Roo tabs (e.g. from Prompts/Settings etc.) to "New Task". I guess we do want to keep that behaviour.

There is a different focus grab that is triggered when the Roo extension becomes visible (e.g. switch from another extension).

I tried removing the useEffect focus grab altogether and adding a case for the "chatButtonClicked" action to the message handler focus grab. Unfortunately the order in which message callbacks for ChatView and the parent mean that the isHidden state isn't yet set up correctly, so this doesn't work. Could be made to work with some more extensive refactoring, and probably would end up cleaner, but for now it's simplest just to make a targetted fix to the handling of the ask_followup_question tool.

I can do a PR for that.

I will look at the 2nd issue now, and then add some more notes here.

[diarmidmackenzie]

On 2, I have found the following:

We use vscode.diff to open the diff:
https://code.visualstudio.com/api/references/commands#vscode.diff:~:text=%2D%20no%20result-,vscode.diff,-%2D%20Opens%20the%20provided

This supports optional controls using TextDocumentShowOptions
https://code.visualstudio.com/api/references/vscode-api#TextDocumentShowOptions

I have experimented with setting the option {preserveFocus: true}, but this doesn't make any difference. I have used a breakpoint after the executeCommand() call to confirm that focus is lost as soon as the vscode.diff command is invoked.

I am on this version of VSCode:

Version: 1.98.2 (user setup)
Commit: ddc367ed5c8936efe395cffeec279b04ffd7db78
Date: 2025-03-12T13:32:45.399Z
Electron: 34.2.0
ElectronBuildId: 11161602
Chromium: 132.0.6834.196
Node.js: 20.18.2
V8: 13.2.152.36-electron.0
OS: Windows_NT x64 10.0.26100

If we wanted to pursue this approach, proposed next step on this would be to create an isolated repro, and raise a bug with the VSCode team. But it looks like this might be a hard one to solve.

For future records, the two lines of code I changed were:

			vscode.commands.executeCommand(
				"vscode.diff",
				vscode.Uri.parse(`${DIFF_VIEW_URI_SCHEME}:${fileName}`).with({
					query: Buffer.from(this.originalContent ?? "").toString("base64"),
				}),
				uri,
				`${fileName}: ${fileExists ? "Original ↔ Roo's Changes" : "New File"} (Editable)`,
				{ preserveFocus: true }
			)

and (for the case where a diff is already open - though I couldn't find a way to test this as apply_diff seems to begin by closing any pre-existing diffs...)

const editor = await vscode.window.showTextDocument(diffTab.input.modified, {preserveFocus: true})

If we can't solve preserving focus on vscode.diff one potential improvement to the workflow would be to wait for user input before displaying the diff. At the moment, the diff is displayed immediately it is ready ("edit files" permissions just controls whether the edit is applied automatically, or whether the user gets a chance to review the diff).

If Roo displayed an indication that a diff was ready for review, but didn't grab focus, then the user could continue with their work without interruption and then view the diff at the point they were ready. That should be a fairly easy change to the workflow, and might be an improvement, if we can't get VSCode to open diffs without losing focus?

[diarmidmackenzie]

#2263 fixes item 1.

@hannesrudolph For item 2, any thoughts on the suggestion of adding an additional user interaction (without any focus grab) before displaying a diff?

I'd be happy to look at this if you think that's a reasonable solution.

[hannesrudolph]

Sure look into it. Would love to test out.