fix: Reset modified state when all changes are undone#1426
fix: Reset modified state when all changes are undone#1426dara-abijo-adfa wants to merge 3 commits into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughRelease Notes
Risks / Best-practice notes
Walkthrough
ChangesUndo-aware modified indicator
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@editor/src/main/java/com/itsaky/androidide/editor/ui/IDEEditor.kt`:
- Around line 145-150: The current implementation stores only savedContentLength
and savedContentHash to detect when edited content returns to its saved state,
creating a data-loss risk from hash collisions. Replace the savedContentHash
variable with a savedContentString variable that stores the actual saved content
as a String. Then in the refreshModifiedState() method (referenced in "Also
applies to: 693-703"), update the logic to perform an explicit content equality
check using .equals() when both the length and hash (computed from the stored
content) match, ensuring that hash collisions do not incorrectly mark files as
unmodified.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 193bcac3-81bc-4b39-be12-d8d6941fc52e
📒 Files selected for processing (2)
app/src/main/java/com/itsaky/androidide/activities/editor/EditorHandlerActivity.kteditor/src/main/java/com/itsaky/androidide/editor/ui/IDEEditor.kt
Replaces the 32-bit `String.hashCode()` implementation with a custom 64-bit FNV-1a hash algorithm. This addresses a potential hash collision vulnerability where a file could be incorrectly marked as unmodified, leading to data loss. Additionally, this resolves a performance bottleneck by computing the hash directly on the `CharSequence`, removing the heavy string allocation (`text.toString()`) that was previously happening every time the file modification state refreshed.
|
Please be careful about possible collisions with PR #1416 |
| } | ||
|
|
||
| private fun computeContentHash(content: CharSequence): Long { | ||
| var hash = -3750763034362895579L // FNV_offset_basis |
There was a problem hiding this comment.
Could you extract these values into constants and document them?
Jira ticket - ADFA-2324
When a file is modified, the file name on the tab shows the asterisk (*) sign to indicate there are unsaved changes. When these changes are undone, putting the file in its initial state, the asterisk sign is still present.
This PR fixes that issue, ensuring the asterisk sign is not displayed when all the file changes are undone.