Skip to content

Conversation

@theaniketgiri
Copy link

Fixes #3558

Problem

Previously, set_save_state(true) was called in the SaveDocument handler before the save dialog even appeared. This caused the document to be marked as saved even if the user cancelled the save dialog, leading to:

  • Loss of the unsaved indicator (asterisk) in the document tab
  • Users thinking their document was saved when it wasn't
  • Potential loss of modifications if the user closed the document

Solution

Moved the save state updates (set_save_state, set_auto_save_state) from the SaveDocument handler to the SavedDocument handler, which only executes after the file has actually been written to disk.

Changes

  • Removed premature set_save_state(true) and related calls from SaveDocument handler
  • Added set_save_state(true) and set_auto_save_state(true) to SavedDocument handler
  • Moved UpdateOpenDocumentsList response to SavedDocument handler

Testing

  • Verified compilation with cargo check
  • The asterisk indicator now correctly remains visible when save is cancelled
  • Document is only marked as saved after successful file write

@timon-schelling timon-schelling marked this pull request as draft January 2, 2026 14:22
@timon-schelling
Copy link
Member

Why the new workflow? That seems unrelated.
Why adding a pnpm lock? We don't use pnpm.

Converted to draft because this not ready for review.

Fixes GraphiteEditor#3558 - Cancelling document saving leads to content/modifications being lost

Previously, set_save_state(true) was called in the SaveDocument handler
before the save dialog even appeared. This caused the document to be
marked as saved even if the user cancelled the save dialog.

Now the save state updates (set_save_state, set_auto_save_state) are
called in the SavedDocument handler, which only executes after the file
has actually been written to disk. This ensures that:
- Cancelling the save dialog keeps the document marked as unsaved
- The asterisk indicator remains visible until the file is truly saved
- No content/modifications are lost if the save is cancelled
@theaniketgiri theaniketgiri force-pushed the fix/save-cancel-dialog-3558 branch from e2f2a87 to 9fe0778 Compare January 2, 2026 14:31
@theaniketgiri
Copy link
Author

Why the new workflow? That seems unrelated. Why adding a pnpm lock? We don't use pnpm.

Converted to draft because this not ready for review.
Hi @timon-schelling, thanks for the review!

You're absolutely right - both the workflow file and pnpm-lock were accidentally included. They were from a different branch I was working on and got mixed in when I created this PR.

I've fixed this now:

Rebased the branch onto master (2fa958a)
Removed the unrelated workflow file
Removed the pnpm-lock file
The PR now only contains the intended changes

@theaniketgiri theaniketgiri marked this pull request as ready for review January 2, 2026 14:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Cancelling document saving leads to content/modifications being lost

2 participants