-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Description
What specific problem does this solve?
1. The Core Problem: A Counter-Intuitive Workflow that Encourages Data Loss
The "Unsaved Changes" confirmation dialog in the Providers configuration panel creates a frustrating and flawed user experience. Instead of preventing data loss, its current implementation actively confuses users and can lead them to discard their own changes. The feature fundamentally disrupts a common workflow: entering credentials and navigating between profiles.
Technical Context: The modal dialog is implemented in the SettingsView component (webview-ui/src/components/settings/SettingsView.tsx) and is triggered when unsaved changes are detected.
2. Observed Behavior in the New Video (Step-by-Step):
This video clearly demonstrates the core usability flaw:
- (0:01 - 0:04): The user starts on the "sonic" profile and successfully switches to the "2.0-flash_OR" profile.
- (0:05 - 0:10): The user begins a critical task: entering an API key into the "OpenRouter API Key" field.
- (0:11 - 0:13): Before finishing or saving, the user attempts to switch back to the "sonic" profile. This is where the workflow breaks.
- (0:13 - 0:15): The "Unsaved Changes" dialog appears, blocking the user. The modal offers two choices, "Cancel" or "Discard changes," neither of which is the user's desired outcome (which is to save the key and then switch).
- (0:15 - 0:29): The user, now trapped in the "2.0-flash_OR" profile, cancels the dialog and repeatedly tries to navigate away, only to be blocked again.
- (0:30 - 0:40): In a final act of frustration, the user clicks "Discard changes" as the most straightforward way to escape the dialog and return to the "sonic" profile. The feature designed to protect data has directly caused the user to lose the API key they just entered.
3. Why This is a Critical Usability Issue:
The current system is worse than having no protection at all. It creates a "trap" where the path of least resistance for the user is to destroy their own work. The user's goal was simple—input a key and switch profiles—but the UI forced them into a confusing loop that ended in data loss. This is the opposite of the feature's intent and must be addressed.
4. The Proposed Solution: A Modern, Seamless Auto-Save System
The "Unsaved Changes" dialog and any manual "Save" or "confirm" buttons should be removed entirely. They should be replaced with a modern, automatic system that is both reliable and transparent to the user.
-
Automatic Saving with Debouncing:
- All configuration changes will be saved automatically in the background.
- Debounce on Text Inputs: To ensure efficiency, a debounce functionality will be implemented for all text fields. The save operation will only trigger after the user has stopped typing for a brief, developer-determined interval (e.g., 500ms).
-
Dynamic Status Indicator:
- A single status dot will be placed in the top-right corner of the panel to provide clear, non-intrusive feedback.
- Orange Dot: Indicates that changes are actively being saved. The save process will restart if the user makes new edits while the dot is orange.
- Green Dot: Confirms that all changes have been successfully saved.
- Grey/Neutral Dot: Indicates an unsaved state or a save error.
-
Intelligent UI Interaction Rules:
- Prevent Profile Switching During Save: To ensure data integrity, the profile selection dropdown will be momentarily disabled while a save is in progress (when the dot is orange).
- Background Saving on Close: Users can close the panel at any time. If a save is in progress, it will continue seamlessly in the background without blocking the UI.
-
Robust Error Handling:
- If a save operation fails (e.g., due to file permissions), the dot will revert to a grey/neutral state.
- A subtle error icon will appear next to the dot. The user can click this icon to see details about the failure.
- For technical debugging, a comprehensive error message will be logged to the "Roo-Code" channel in the VS Code output logs.
Code_02_22_20_41___9267.mp4
Additional context (optional)
No response
Roo Code Task Links (Optional)
No response
Request checklist
- I've searched existing Issues and Discussions for duplicates
- This describes a specific problem with clear impact and context
Interested in implementing this?
- Yes, I'd like to help implement this feature
Implementation requirements
- I understand this needs approval before implementation begins
How should this be solved? (REQUIRED if contributing, optional otherwise)
No response
How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)
No response
Technical considerations (REQUIRED if contributing, optional otherwise)
No response
Trade-offs and risks (REQUIRED if contributing, optional otherwise)
No response
Metadata
Metadata
Assignees
Labels
Type
Projects
Status