Focus Lost in Chat Text Box After Alt+Tab

[libertyteeth]

App Version

3.11.3

API Provider

OpenRouter

Model Used

Any router, any model

Actual vs. Expected Behavior

What happened?

When a user is typing in the Roo Code chat text box, switches away from VSCode using Alt+Tab, and then switches back using Alt+Tab again, focus is lost from the chat text box. This forces the user to manually click inside the text box to continue typing, disrupting workflow and keyboard-based navigation.

A workaround exists: after switching back, if the user presses Ctrl+V to paste, the text box regains focus. However, this is still an interruption to the natural workflow.

Expected behavior

After switching back to VSCode with Alt+Tab, focus should remain in the chat text box, allowing the user to continue typing immediately without requiring a mouse click.

Detailed Steps to Reproduce

1. Open VSCode with Roo Code extension
2. Start typing in the Roo Code chat text box
3. Press Alt+Tab to switch to another application
4. Press Alt+Tab again to switch back to VSCode
5. Try to continue typing - the text box is no longer focused

Relevant API Request Output

Additional Context

Technical Analysis

The issue occurs because the ChatView component doesn't properly handle window focus events. When the window loses focus and then regains it, the text area doesn't automatically regain focus.

The fix implemented

Added a window focus event listener in the ChatView.tsx component that explicitly refocuses the text area when the window regains focus:

// Effect to restore focus to the text area when the window regains focus
useEffect(() => {
  const handleWindowFocus = () => {
    // Check if the view is visible and the text area should be focusable
    if (!isHidden && !textAreaDisabled && !enableButtons) {
      // Use setTimeout to ensure focus happens after the event loop cycle
      setTimeout(() => {
        textAreaRef.current?.focus()
      }, 0)
    }
  }

  window.addEventListener("focus", handleWindowFocus)

  // Cleanup listener on component unmount
  return () => {
    window.removeEventListener("focus", handleWindowFocus)
  }
  // Dependencies ensure the effect re-runs if these conditions change
}, [isHidden, textAreaDisabled, enableButtons])

The listener checks if the text area is eligible for focus (visible, not disabled, and no buttons are enabled) and, if so, explicitly focuses it when the window regains focus. The setTimeout ensures the focus action happens after the event loop cycle for better reliability.

Environment

• Version: 3.11.3
• Provider: Any (not provider-specific)
• Model: Any (not model-specific)
• OS: All (Windows, macOS, Linux)

Additional Context

This issue disrupts the flow for keyboard-focused users who frequently switch between VSCode and other applications while working with Roo Code. The implementation is minimal and follows React best practices for effect handling and focus management.

The fix has been tested and works as expected. Unit tests within roo-code/ did show failures in TerminalRegistry.test.ts, but these appear unrelated to the focus fix applied in the webview UI code.

Note: Previous attempts to fix this issue may have used different approaches (such as using useMount or a different useEffect with setTimeout), but the current implementation with the window focus event listener is the most effective solution that specifically addresses the Alt+Tab focus issue.

[libertyteeth]

Note: there appears to be a race condition. The fix works intermittently.

It appears that the conflict is with the existing 50ms attempt to make this work via "dumb timing."

I am working on a state-detecting approach. Just in case anyone is trying to perform the fix I outlined above -- it worked for me last night, but then didn't work today, and then from testing I determined it was intermittent: the most fun type of bug! :)

[diarmidmackenzie]

I don't think the test should include !enableButtons

Even when buttons are present / enabled, the text box is still focusable.

I see you are using the same test as:

1. https://github.com/RooVetGit/Roo-Code/blob/e7a1db83c0f05cb2fb02d8b5f1472cc09e6142bf/webview-ui/src/components/chat/ChatView.tsx#L498 (applies when extension becomes visible / invisible)
2. https://github.com/RooVetGit/Roo-Code/blob/e7a1db83c0f05cb2fb02d8b5f1472cc09e6142bf/webview-ui/src/components/chat/ChatView.tsx#L553 (applies when switching back to the Chat tab - and potentially in other cases).

However I think both of these are bugged, for example...

• Get the LLM to perform an action that results in buttons - e.g. disable auto-approval for reads and ask it to read a file.
• With buttons showing, click in the text area, so it has focus
• Now, either switch to a different extension and back, or switch to a different tab and back without creating a new task (e.g. switch to Prompts, then click "Done"). In both cases, focus should return to the text box, but it doesn't.

A potential fix is to remove the !enableButtons condition in each case.

However that will re-introduce (and make worse) a problem I just fixed in #2263, where task completion resulted in focus being grabbed, which isn't what you want if you are doing some other work (e.g. hand-editing a file) while waiting for Roo to complete it's task (see also #1358).

I think a comprehensive fix for this is going to need a separate state to track whether the ChatTextArea does or does not have focus. It's not possible to determine this reliably from the existing state (because you can set/remove focus from the ChatTextArea without any of the other state changing).

[diarmidmackenzie]

In relation to this specific bug, I can't reproduce this myself on Windows with 3.11.4. Maybe there are some OS-specific differences regarding how focus is maintained between tab switches?

[libertyteeth]

I think a comprehensive fix for this is going to need a separate state to track whether the ChatTextArea does or does not have focus. It's not possible to determine this reliably from the existing state (because you can set/remove focus from the ChatTextArea without any of the other state changing).

Thank you, I agree. There are definitely differences across platforms.

I think a "UI manager" might be helpful -- perhaps an AI can handle that task?

Platform management code might make sense, so that Roo Code could just say, "set focus here on this condition" and have the platform management layer handle it.

I started working on the below but got distracted; feel free to run with it, provide feedback, etc:

https://github.com/libertyteeth/roo-fixes/pull/2

[joecklau]

On v3.11.12 on Windows, I get similar issue.
After some run, whenever I do pasting in Visual Code, no matter using Ctrl+V or right-click menu clicking "paste", the pasted content always go to terminal even key-typing focus is at Roo chatbox.

[NamesMT]

After some hours of debug, I found two concrete reproducible bugs with VSCode's webview rendering, this happens to all other extensions that is using Webview, together they are the main cause of this issue.

1: upon re-focusing the VSCode window, if the Enter Tab key is released after Alt, the menu bar will be focused.

2: upon focusing of another element in the editor (to reproduce, try press Alt twice), the webview's focus is lost completely, in normal editor and non-webview inputs, the element will regain the focus.