[BUG] No UI indicator when Background Editing writes long files

[lemiesz]

Description

When the experimental Background Editing feature is enabled and Roo creates new long files, there is no visual indicator that the operation is in progress. This makes it appear as if the application has crashed or frozen.

Steps to Reproduce

1. Enable the Background Editing experimental feature
2. Request Roo to create new files
3. Roo responds with "I have finished gathering information I will now create the needed files"
4. No loading indicator or UI signifier appears while files are being written

Expected Behavior

There should be a loading indicator, progress bar, or some UI feedback showing that files are being written in the background.

Actual Behavior

No visual feedback is provided, making it look like the app has frozen or crashed when it's actually writing long files.

Environment

• Feature: Background Editing (experimental)
• Operation: Creating new long files

Impact

Users may think the application has crashed and attempt to restart it, potentially interrupting the file writing process.

Additional Context

This issue is related to but distinct from #8736, which is about editor visibility during background editing. This issue specifically concerns the lack of progress feedback.

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Root Cause

When the preventFocusDisruption experimental feature (Background Editing) is enabled, the file writing tools skip sending a partial message to the UI that would normally trigger a progress indicator. In the normal flow, task.ask("tool", partialMessage, true) is called before showing the diff editor, which displays a loading spinner in the chat. When background editing is enabled, this step is skipped entirely.

Proposed Solution

Add a partial message to the UI in all edit tools when preventFocusDisruption is enabled, before the file operation begins. This will show a progress indicator (spinner) in the chat while files are being written in the background.

The affected files are:

1. src/core/tools/WriteToFileTool.ts - Lines 118-143
2. src/core/tools/ApplyDiffTool.ts - Around line 134
3. src/core/tools/MultiApplyDiffTool.ts - Around line 581
4. src/core/tools/SearchAndReplaceTool.ts - Around line 179
5. src/core/tools/SearchReplaceTool.ts - Around line 172
6. src/core/tools/EditFileTool.ts - Around line 250

For each tool, when isPreventFocusDisruptionEnabled is true, I'll add:

// Show progress indicator in UI while preparing the file
const partialMessage = JSON.stringify(sharedMessageProps)
await task.ask("tool", partialMessage, true).catch(() => {})

This displays a loading spinner in the chat row (via the existing ProgressIndicator component in ChatRow.tsx) while the background file operation is in progress. The user will see visual feedback that Roo is working, preventing confusion about whether the app has frozen.

Benefits

• Users will see a progress indicator during background file operations
• The existing UI components (ProgressIndicator) are already in place and handle this display
• Minimal code changes required - just adding the missing partial message calls
• Consistent behavior across all edit tools

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[lemiesz]

@roomote i approve this plan

[roomote]

Thanks for the approval! I'll proceed with implementing the plan now. I'll add progress indicator messages to all the edit tools when background editing is enabled and open a PR shortly.

[roomote]

I've opened PR #10506 with my attempt at addressing this issue. The fix adds a progress indicator (spinner) in the chat UI when Background Editing is enabled, so users will see visual feedback while files are being prepared in the background.

Feedback welcome!

[wklaaks]

I am not sure if this is related, but I am also experiencing a behavior which sounds similar.
When I do NOT have "Write Auto Approved", then quite frequently I see the 'Approve' button pop up, but at that point, there is still no 'Roo's Changes (Editable)' file/window being displayed. You are then puzzled what it is that you are being asked to Approve. Then, depending on the job at hand, it can take many more seconds, or 10s of seconds before that window pops up and then the 'Approve' changes to 'Save / Reject' buttons. So very confusing.
My worry is that I am not sure what the consequences are should I click 'Approve' before the LLM has completed streaming the edit changes over to Roo.
PS: I just noticed that this may be linked to Checkpoints. The 'Roo's Changes (Editable)' only pops up when the Checkpoint completes or times out (watching for this in View->Output->Too).