Skip to content

fix: incorrect saving logic after duplicated slide#163

Merged
GursheenK merged 3 commits intofrappe:developfrom
GursheenK:duplicate-slide-loss-issue
Apr 13, 2026
Merged

fix: incorrect saving logic after duplicated slide#163
GursheenK merged 3 commits intofrappe:developfrom
GursheenK:duplicate-slide-loss-issue

Conversation

@GursheenK
Copy link
Copy Markdown
Member

Fixed infinite autosave loop and slide loss caused by duplicating slides one after the other due to name getting defined as undefined instead of name being an empty string, which was checked to evaluate the dirty flag in consecutive saves and led to an incorrect dirty value.

  1. User duplicated slide and getNewSlide assigns name: '' to newly added slide. isDirty becomes true and save triggers.
  2. User duplicated the newly added slide while the previous save call is still being processed. Another save call is triggered.
  3. Server assigns a new name to the 2nd slide and on completion updateNewlyAddedSlideUUIDs runs but at this point there are three slides - the original slide, the first duplicated slide and the second duplicated slide but the very first save call only had 2 slides to save so its response does not have the third slide at all so presentationResource.value.doc.slides[idx]?.name is undefined for the third slide and is assigned to the name key by the first save call.
  4. The second save call completes and server assigns a new name to the third slide and on completion of that call updateNewlyAddedSlideUUIDs runs again but at that point the third slide name is undefined and not '' so the newly returned name is not updated.
  5. presentationDoc.value = presentationResource.value.doc runs but now presentationDoc.slides[2].name = 'real-uuid' (from the second save response which had all 3 slides).
  6. Autosave checks dirty state and isDirty compares original[2].name = 'real-uuid' vs current[2].name = undefined. hasSlideChanged hits slideState.name != '' && slideState.name != originalState.name — undefined != '' is true → dirty forever. Every iteration destroys the server's slide row and creates a new one.

On reload, we get back whichever UUID was last committed but since the save was still running, if we reload mid-save the server may have just deleted the previous row and not yet inserted the new one, resulting in only 2 slides coming back instead of 3.

Before

Screen.Recording.2026-04-13.at.5.22.10.AM.mov

After

Screen.Recording.2026-04-13.at.5.22.56.AM.mov

@GursheenK GursheenK merged commit 289a546 into frappe:develop Apr 13, 2026
2 checks passed
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.

1 participant