[BUG] Prompts editor: Save button doesn’t activate on edit; requires two clicks to persist

[beccare]

Type

Bug

Problem / Value

Editing any prompt in Settings → Prompts does not activate the Save button. Users must click once to “wake” the button and then click again to persist changes, leading to confusion and accidental loss of edits.

Context

• App: 3.23.12
• Provider: OpenRouter
• Model: any
• Area: Settings → Prompts (textarea edits)

Reproduction

1. Open Settings → Prompts
2. Edit any prompt in the textarea
3. Observe the Save button remains faded/inactive
4. Click Save once → button appears active, but changes are not saved
5. Click Save again → changes persist
6. Navigate away and back to confirm actual save behavior

Expected

Save button activates immediately on content change and a single click persists the change.

Actual

Save button remains inactive after edit and requires two clicks to persist changes (first to activate, second to save).

Acceptance Criteria

• Save button enables on any prompt textarea change (e.g., input/change event)
• A single click saves the updated prompt
• Navigating away and back shows the saved content without extra clicks
• No regressions for other settings inputs

Notes

Consider debounced change handling if needed, but ensure clear enabled/disabled state tied to content diffs.

[daniel-lxs]

Hey, I’ve been looking into this and I think I found the issue.

It looks like the onChange handler in PromptsSettings might be mishandling empty strings. Right now it does:

const value =
  (e as unknown as CustomEvent)?.detail?.target?.value ||
  ((e as any).target as HTMLTextAreaElement).value

The problem is that if the first value is an empty string, it’s falsy, so it falls back to the second one even if the first was valid. That could cause weird behavior.

Also, when it trims the string:

const trimmedValue = value.trim()
updateSupportPrompt(activeSupportOption, trimmedValue || undefined)

If the user clears the prompt, it gets converted to undefined, which might be throwing off the update logic.

Switching to nullish coalescing (??) instead of || would help:

const value =
  (e as unknown as CustomEvent)?.detail?.target?.value ??
  ((e as any).target as HTMLTextAreaElement).value

That way we preserve empty strings and handle both event types more reliably.

[MuriloFP]

PR #6026 has been created to address this issue: #6026

Edit: I could not figure out the issue. It seems to be more than the scope that @daniel-lxs suggested.

The changes are not detected until you click out of the prompt input box. Just typing in it won't trigger the save button active state, it remains greyed out until you click somewhere else outside the box.