Category: feature request
Surface: Desktop (observed on 0.5.7, macOS; behavior matches current main)
Problem
A composer draft with attached images does not survive an app quit or machine reboot:
- Queued image attachments are memory-only.
desktop/src/features/messages/lib/backgroundMediaUploadStore.ts keeps queued files in a module-level Map (queuedAttachmentsByDraftKey), and useDraftPersistSnapshot.ts is explicit about it: "Local files cannot be persisted, so clear them at a draft-key boundary." Since upload only happens at send time, an attached-but-unsent image is always lost on restart.
- Draft text is only flushed on a draft-key change. The draft store does persist to
localStorage (useDrafts.ts), but the only write path from the composer is the effect cleanup in useDraftPersistSnapshot.ts, which fires when the user navigates to another channel/thread or the composer unmounts. There is no flush on window close, so quitting the app (or a reboot) while still sitting in the compose box loses the text too — even though the persistence layer exists.
Repro: type a message in any channel, attach an image, quit Buzz without switching channels, relaunch → composer is empty. Switch channels first before quitting → text and already-uploaded imeta survive, the queued local image does not.
Request
- Persist queued attachments to disk (e.g. the Tauri app-data dir, keyed by draft key, mirroring the existing
localStorage draft schema with a file-path reference), restore them on launch, and garbage-collect on send/clear.
- Flush the current draft on window close (Tauri
onCloseRequested / beforeunload) so in-place text drafts survive quit as well.
The first item is the user-facing gap; the second looks like a small win since persistDraftEntry already exists.
Related but distinct: #5259 covers composer text loss on iOS; this issue is about Desktop, primarily the attachment gap.
User impact
Anyone who composes a longer post with screenshots/photos and gets interrupted by an app update, crash, or reboot loses the attachments (and usually the text) silently. For teams where the desktop app auto-updates, this happens without the user ever choosing to quit.
Category: feature request
Surface: Desktop (observed on 0.5.7, macOS; behavior matches current
main)Problem
A composer draft with attached images does not survive an app quit or machine reboot:
desktop/src/features/messages/lib/backgroundMediaUploadStore.tskeeps queued files in a module-levelMap(queuedAttachmentsByDraftKey), anduseDraftPersistSnapshot.tsis explicit about it: "Local files cannot be persisted, so clear them at a draft-key boundary." Since upload only happens at send time, an attached-but-unsent image is always lost on restart.localStorage(useDrafts.ts), but the only write path from the composer is the effect cleanup inuseDraftPersistSnapshot.ts, which fires when the user navigates to another channel/thread or the composer unmounts. There is no flush on window close, so quitting the app (or a reboot) while still sitting in the compose box loses the text too — even though the persistence layer exists.Repro: type a message in any channel, attach an image, quit Buzz without switching channels, relaunch → composer is empty. Switch channels first before quitting → text and already-uploaded imeta survive, the queued local image does not.
Request
localStoragedraft schema with a file-path reference), restore them on launch, and garbage-collect on send/clear.onCloseRequested/beforeunload) so in-place text drafts survive quit as well.The first item is the user-facing gap; the second looks like a small win since
persistDraftEntryalready exists.Related but distinct: #5259 covers composer text loss on iOS; this issue is about Desktop, primarily the attachment gap.
User impact
Anyone who composes a longer post with screenshots/photos and gets interrupted by an app update, crash, or reboot loses the attachments (and usually the text) silently. For teams where the desktop app auto-updates, this happens without the user ever choosing to quit.