fix: Fix Auto Approve UI Closing #2579

[Mnehmos]

Related GitHub Issue

Closes: #2579

Description

This pull request re-implements the changes from the original PR #4371.

This PR addresses issue #2579, which pointed out confusing UI behavior in the auto-approve feature. The changes ensure that the UI state is always clear and unambiguous to the user.

The primary changes are:

• webview-ui/src/components/chat/AutoApproveMenu.tsx:
  • The main "Auto-Approve" checkbox is now disabled when no individual actions are approved.
  • Enabling an individual action now automatically enables the main auto-approve setting.
• webview-ui/src/components/settings/AutoApproveToggle.tsx:
  • The toggle buttons now correctly reflect their individual state while also visually indicating whether the overall auto-approve setting is enabled.
• .gitignore:
  • Added webview-ui/node_modules and webview-ui/dist to the ignore list.

These changes ensure that the user's preference is respected, improving the overall user experience.

Test Procedure

1. Go to the chat view.
2. Open the Auto-approve menu.
3. Verify the main checkbox is disabled when no options are selected.
4. Select an option (e.g., "Read-Only").
5. Verify the main checkbox becomes checked.
6. Uncheck all options.
7. Verify the main checkbox becomes unchecked and disabled.
8. Collapse the menu with an option selected.
9. Verify the checkbox is checked and the selected option is displayed.
10. Uncheck the checkbox in the collapsed state.
11. Verify the text changes to "None".

Type of Change

• 🐛 Bug Fix: Non-breaking change that fixes an issue.
• ✨ New Feature: Non-breaking change that adds functionality.
• 💥 Breaking Change: Fix or feature that would cause existing functionality to not work as expected.
• ♻️ Refactor: Code change that neither fixes a bug nor adds a feature.
• 💅 Style: Changes that do not affect the meaning of the code (white-space, formatting, etc.).
• 📚 Documentation: Updates to documentation files.
• ⚙️ Build/CI: Changes to the build process or CI configuration.
• 🧹 Chore: Other changes that don't modify src or test files.

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Code Quality:
  • My code adheres to the project's style guidelines.
  • There are no new linting errors or warnings (npm run lint).
  • All debug code (e.g., console.log) has been removed.
• Testing:
  • New and/or updated tests have been added to cover my changes.
  • All tests pass locally (npm test).
  • The application builds successfully with my changes.
• Branch Hygiene: My branch is up-to-date (rebased) with the main branch.
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Changeset: A changeset has been created using npm run changeset if this PR includes user-facing changes or dependency updates.
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

Documentation Updates

• No documentation updates are required.

Additional Notes

This PR is a recreation of #4371 after the original branch was accidentally deleted.

---

Important

Fixes UI behavior in AutoApproveMenu.tsx and AutoApproveToggle.tsx to ensure clear auto-approve state indication and updates .gitignore.

• Behavior:
  • In AutoApproveMenu.tsx, the main "Auto-Approve" checkbox is disabled when no actions are approved and is automatically enabled when any action is selected.
  • In AutoApproveToggle.tsx, toggle buttons reflect their individual state and indicate if the overall auto-approve setting is enabled.
• Misc:
  • Added webview-ui/node_modules and webview-ui/dist to .gitignore.

^{This description was created by for 629aee0. You can customize this summary. It will automatically update as commits are pushed.}

[daniel-lxs]

Hey @Mnehmos, Thank you for working on this fix!

I took a look at your PR and left a couple of suggestions that are worth taking a look at.

Let me know if you have any questions!

[daniel-lxs]

The state synchronization logic here seems complex and the extensive comments suggest uncertainty about the approach. Could we simplify this by creating a more robust state update mechanism?

Specifically, the else branch (lines 84-95) acknowledges that it doesn't handle the case where disabling an action should potentially disable the main checkbox. This could lead to inconsistent UI states.

Consider extracting this logic into a separate function that can properly calculate the new state based on all current toggle values, rather than relying on "future render cycles".

[daniel-lxs]

The logic here only handles enabling the main checkbox when an individual action is enabled, but doesn't handle the reverse case. When the last enabled action is disabled, the main checkbox should also be disabled automatically.

Consider adding logic to check if all toggles are now false and update autoApprovalEnabled accordingly:

if (value === true) {
  setAutoApprovalEnabled(true)
  vscode.postMessage({ type: "autoApprovalEnabled", bool: true })
} else {
  // Check if this was the last enabled toggle
  const updatedToggles = { ...toggles, [key]: false }
  const hasAnyEnabled = Object.values(updatedToggles).some(v => !!v)
  if (!hasAnyEnabled) {
    setAutoApprovalEnabled(false)
    vscode.postMessage({ type: "autoApprovalEnabled", bool: false })
  }
}

[daniel-lxs]

Were these changes accidental?

[Mnehmos]

Yes yes and yes. This was my first PR attempt, I'll review all of these and come with a much more solid approach. Thank you for reviewing these changes.

[daniel-lxs]

Hey @Mnehmos, Thank you for taking a look at the suggestions!

I was testing the auto-approve buttons and noticed a weird behavior:

2025-06-11_08-01-55.mp4

It seems like the buttons are enabled or disabled randomly, can you take a look?