feat: add automatic selection context to user messages #9213
Conversation
- Add selection context fields to WebviewMessage and ExtensionMessage types - Implement selection capture in ChatView on component mount - Add backend message handler to capture editor selection with line numbers - Store selection context in Task instance for use in environment details - Include selection context at start of environment details sent to LLM - Automatically clear selection context after use to prevent persistence - Add comprehensive tests for selection context functionality - Convert VSCode 0-based line numbers to 1-based for user-friendly display - Handle both workspace-relative and absolute file paths This allows users to select text in the editor and ask questions like "fix this" or "what does this do" without explicitly pasting code. The selection is automatically included as hidden context for the LLM.
dosubot
bot
added
size:L
All previous issues resolved. No new issues found.
Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues. |
![roomote[bot]](https://avatars.githubusercontent.com/in/1546624?s=60&v=4){kind=small}
| useMount(() => { | ||
| textAreaRef.current?.focus() | ||
| // Request initial selection context when component mounts | ||
| vscode.postMessage({ type: "requestSelectionContext" }) | ||
| }) |
There was a problem hiding this comment.
Stale selection context can be sent with messages if the user changes their selection after component mount but before sending a message. The requestSelectionContext call on mount stores the selection in the task, but if the user then selects different text and sends a message, the old selection context will be included. Selection context should be captured at message send time, not at component mount time, to ensure it reflects the user's current selection.
Fix it with Roo Code or mention @roomote and request a fix.
hannesrudolph
added
the
Issue/PR - Triage
| // Store selection context in current task for use in environment details | ||
| const currentTask = provider.getCurrentTask() | ||
| if (currentTask) { | ||
| currentTask.selectionContext = { | ||
| selectedText, | ||
| selectionFilePath: relativeFilePath, | ||
| selectionStartLine: startLine, | ||
| selectionEndLine: endLine, | ||
| } | ||
| } |
There was a problem hiding this comment.
Selection context stored here persists until explicitly overwritten, which can cause stale context from a previous selection to leak into new messages. If a user selects text, the context is stored in the task, then the user changes their selection or clears it before sending a message, the old selection context will still be sent. The stored context should be cleared when the selection changes or when a message is sent to prevent stale data from being included in subsequent messages.
Fix it with Roo Code or mention @roomote and request a fix.
src/core/task/Task.ts
Outdated
| selectionContext?: { | ||
| selectedText: string | ||
| selectionFilePath: string | ||
| selectionStartLine: number | ||
| selectionEndLine: number | ||
| } |
There was a problem hiding this comment.
Selection context from a previous task can leak into a new task if the user starts a new task without changing their editor selection. When clearTask is called (which eventually creates a new task), the selection context stored in the old task instance is not explicitly cleared. If the same selection remains active in the editor, the requestSelectionContext call on mount will capture and store it again, but there's a brief window where the old context could be used. The selection context should be explicitly cleared when clearing/aborting a task to prevent any possibility of context leakage between tasks.
Fix it with Roo Code or mention @roomote and request a fix.
Fixed the reported issues. All local checks passed. |
- Move selection context request from mount-time to send-time in ChatView - Remove storage of selection context in Task instance to prevent staleness - Pass selection context through message flow as ephemeral parameter - Add getAndClearSelectionContext() method to Task for one-time use - Update tests to reflect new architecture with mocked getter method - Add selectionContext to CreateTaskOptions interface This ensures selection context is always fresh when sent and automatically cleared after use, preventing context leakage between messages.
| // Request fresh selection context before sending | ||
| vscode.postMessage({ type: "requestSelectionContext" }) | ||
|
|
||
| if (messagesRef.current.length === 0) { | ||
| vscode.postMessage({ type: "newTask", text, images }) | ||
| vscode.postMessage({ | ||
| type: "newTask", | ||
| text, | ||
| images, | ||
| ...(selectionContext || {}), | ||
| }) |
There was a problem hiding this comment.
Race condition between requesting selection context and sending the message. The code calls vscode.postMessage({ type: "requestSelectionContext" }) on line 572, then immediately sends the message on line 576 using ...(selectionContext || {}). Since requestSelectionContext is asynchronous and updates state via the message handler (lines 767-775), the message will be sent with stale selectionContext state before the fresh context arrives. This defeats the purpose of requesting fresh context at send-time.
Fix it with Roo Code or mention @roomote and request a fix.
|
@roomote why does the webview need to get the selection context? Can't the extension just get it when it needs it? |
Refactored selection capture to be handled directly by the extension instead of the webview. All local checks passed. |
- Remove selection context state management from ChatView - Remove requestSelectionContext message type and handler - Extension now captures selection directly in newTask and askResponse handlers - Eliminates race condition between selection request and message send - Simplifies architecture by removing unnecessary webview complexity
packages/types/src/task.ts
Outdated
| selectionContext?: { | ||
| selectedText: string | ||
| selectionFilePath: string | ||
| selectionStartLine: number | ||
| selectionEndLine: number | ||
| } |
There was a problem hiding this comment.
@roomote this is repeated a lot - should we move it into a type?
Working on extracting the repeated selection context type definition into a shared type. |
This PR implements automatic capture of editor selection as hidden context for LLM messages, allowing users to select text and ask questions like "fix this" or "what does this do" without explicitly pasting code.
Changes
Type Definitions
WebviewMessageandExtensionMessagetypesselectedText,selectionFilePath,selectionStartLine,selectionEndLineFrontend (ChatView)
requestSelectionContextmessageBackend (Message Handler)
requestSelectionContextcase to capture active editor selectionTask Management
selectionContextproperty to Task classnewTaskandaskResponsecasesEnvironment Details
Testing
User Experience
Users can now:
The feature seamlessly integrates with the existing message flow and follows established patterns in the codebase.
Important
This PR adds automatic capture of editor selection as context for LLM messages, enhancing user interactions by including selected text and file details without manual input.
selectedText,selectionFilePath,selectionStartLine,selectionEndLine.requestSelectionContextmessage.requestSelectionContextto capture active editor selection.Taskinstance.selectionContextproperty toTaskclass.newTaskandaskResponsecases.This description was created by
for e25c2d6. You can customize this summary. It will automatically update as commits are pushed.