fix: don't mark filter edit dirty on render#247
Open
salmon-21 wants to merge 1 commit into
Open
Conversation
Rendering state back into the edit form called EditText.setText(), which fired the field's text-changed watcher and sent an Update command, flipping isDirty to true even though the user changed nothing. Returning to the filter list then wrongly prompted "Discard changes?". doAfterTextChanged now returns a setter that suppresses the watcher while applying a programmatic update, and render() uses it instead of setText(). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #248.
Summary
The filter edit screen shows the "Discard changes?" dialog (added in #245) even when the user changed nothing.
render()pushes state into the fields viasetTextIfDifferent(...) → EditText.setText(...). ThatsetTextfires the field'sdoAfterTextChangedwatcher, which sends anUpdate…command, and the reducer flipsisDirty = true— so a pure render is mistaken for a user edit.Because the watcher is attached on
onResume/ detached ononPause(core/ui/base/.../TextViewExt.kt), the spurious dirty reliably triggers after any onPause→onResume cycle (app switch, dialog, etc.) where a render runs with the watcher attached.Fix
doAfterTextChangednow returns a setter that detaches the watcher while applying a programmatic update, then restores the lifecycle's attachment state.render()uses that setter (viasetTextIfDifferent) instead ofsetText(), so rendering state back into the form no longer looks like a user edit. Genuine typing still flows through the watcher unchanged.This keeps the
isDirty-in-reducer design and the TEA back-routing exactly as reviewed in #245 — only the programmatic-setTextpath is made watcher-safe.Test plan
:core:ui:baseand:feature:filters:presentationcompile clean.🤖 Generated with Claude Code