Improved handling of Text Area focus state

[diarmidmackenzie]

Context

After making a pragmatic fix under PR#2263, I came across #2189, and as per comments there, I realized that there were various further issues with how focus on the text box is managed.

As described there, when the Roo Chat tab becomes visible again (either by switching between Roo tabs) or by switching between VSCode extensions, there is no way to determine from existing state whether or not focus should be re-instated on the text panel.

This PR explicitly tracks whether there is focus on this panel, and then re-instates it when the panel comes back into view.

Implementation

Basic approach is:

• track focus and blur events to keep track of whether the text area has focus.
• re-instate this when the chat view reappears.
• simplify ChatView by pulling this code into a custom hook.
• revert previous fix for Fix for focus grabbing when follow-up returns + Unit Test #2263, which is no longer required.

A bit of complexity arose because of the various ways that the text area can "blur" that we don't want to count as blurring, in particular

• switching to a new Roo tab (Prompts, MCP Servers etc.)
• switching to a different VS Code extension.

To accommodate the last of these, I had to extend the ExtensionMessage API to add a new "didBecomeInvisible" message that fires when the VSCode extension is hidden.

I added a decent set of Unit Tests to cover these various flows as well.

Screenshots

N/A

How to Test

Key manual tests are:

• toggle focus on the text area by clicking on / off
• focus state should be preserved when switching to a different Roo tab (e.g. Prompts, MCP Servers) and back
• focus state should be preserved when switching to a different VSCode extension so that Roo is hidden (or hiding Roo) and then switching back to Roo.

Get in Touch

diarmid/diarmidm on Discord

---

Important

Improves text area focus handling in ChatView by tracking focus state and reinstating it when the view becomes visible, using a new useFocusPreservation hook.

• Behavior:
  • Tracks focus and blur events in ChatView.tsx to manage text area focus state.
  • Reinstates focus when the chat view becomes visible again.
  • Introduces useFocusPreservation hook in useFocusPreservation.tsx to handle focus state management.
  • Reverts previous fix for Fix for focus grabbing when follow-up returns + Unit Test #2263 as it's no longer needed.
• ExtensionMessage:
  • Adds didBecomeInvisible action to ExtensionMessage in ExtensionMessage.ts.
• Tests:
  • Adds unit tests in ChatView.test.tsx to verify focus behavior when view visibility changes.

^{This description was created by for 86d9722. It will automatically update as commits are pushed.}

[ellipsis-dev]

Use the primitive boolean type instead of Boolean for the isHidden parameter.

Suggested change

	export function useFocusPreservation(element: HTMLElement | null, isHidden: Boolean) {
	export function useFocusPreservation(element: HTMLElement | null, isHidden: boolean) {

[diarmidmackenzie]

Fixed

[changeset-bot]

⚠️ No Changeset found

Latest commit: 4acb29e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[libertyteeth]

Added the below to a closed PR ( #2263 (comment) ); I see this one's open. Haven't reviewed differences between the techniques; mine's a state machine approach. Hope this helps!

---

I mentioned this in #2189 (comment) , just wanted to note it here: I've worked on a fairly comprehensive state machine for maintaining focus.

It may be lacking a few edge cases? I put it here a few days ago, then got busy with life :)

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

[diarmidmackenzie]

Added the below to a closed PR ( #2263 (comment) ); I see this one's open. Haven't reviewed differences between the techniques; mine's a state machine approach. Hope this helps!

I mentioned this in #2189 (comment) , just wanted to note it here: I've worked on a fairly comprehensive state machine for maintaining focus.

It may be lacking a few edge cases? I put it here a few days ago, then got busy with life :)

libertyteeth/roo-fixes#2

The two fixes attempt to implement different behaviours, so it depends a bit what the desired behaviour is (which I don't think is clear, and is not specified anywhere that I know, so we're both working from our intuition about what we would expect, where we might have different expectations/intuition).

The scenarios I focused on in my fix were:

• Switch to a different tab and back to chat view (isHidden true/false)
• Extension going invisible / visible.

The function I implemented was to always restore the focus on TextArea to what it was before - i.e. if it was focused before ChatView/extension was hidden, make it focused when ChatView becomes visible/not hidden again; and if it was not focused before, then don't focus it again.

This can only be achieved by actively monitoring for focus/blur events on TextArea (which I added; the existing code and your new code don't do this).

Some scenarios that I didn't consider/cover, that look to be handled in your new code:
1 - Restore of focus when Alt-Tabbing to/from the app. On my windows system, I could not reproduce this issue
2 - Autofocus on TextArea when switching to a different task through history. It's not obvious to me that this is desired behaviour (if it is, my code could be accommodated to cover this).
3 - Autofocus on TextArea when user clicks anywhere in the ChatWindow.

Other points to highlight from my PR, that I think are definitely beneficial.

• Pulling the focus-related logic into a separate hook, to reduce code complexity in ChatView
• Unit Tests, so we will be alerted to future regressions in this area.

If we can identify additional behaviours that are desirable, but not yet implemented in my PR (e.g. items 1-3 above, I'd be happy to extend my PR and the UTs to cover them).

[hannesrudolph]

@diarmidmackenzie
Based on recent updates to the focus handling (specifically, allowing messages to be entered while Roo is processing), it seems this PR is no longer applicable. I've reached out via Discord to confirm with you, but I'll close this for now to keep things tidy.

If this assessment isn't correct or there's more you'd like to discuss, please let us know and we can revisit this. For future contributions, please follow our issue-first approach.

Thanks again for your effort!

[diarmidmackenzie]

Seems reasonable. Thanks for checking in on this.