Memo does not display pasted or dragged images

[hyper-charlie]

Description

Images pasted or dragged into the memo portion of notes do not display. Instead, users see either a white space or an invisible box with dots (placeholder).

Steps to Reproduce

1. Open a note and navigate to the memo section
2. Paste a screenshot (using CTRL+Shift+CMD+4 on macOS to capture screen to buffer, then paste)
3. Or drag a PNG image directly into the memo
4. Observe the result

Expected Behavior

The image should display in the memo with proper rendering.

Actual Behavior

• Pasted images show an invisible box with dots (failed render)
• Dragged images show a large white space
• Images do not render or display in either case

Additional Notes

• Both PNG files and screenshots from clipboard have been tested
• Issue affects memo section specifically
• Resizing capability for images would also be a nice-to-have

Environment

• Platform: macOS (aarch64)
• OS Version: macOS 26.3
• App Version: 1.0.10
• Build: 58a816d

[devin-ai-integration]

Codebase Exploration Findings

Image Paste/Drop Flow

The image handling pipeline for the memo editor involves these components:

1. packages/tiptap/src/shared/extensions/index.ts — Defines AttachmentImage (extends @tiptap/extension-image) with a custom attachmentId attribute, and configures @tiptap/extension-file-handler to handle paste/drop of image/png, image/jpeg, image/gif, image/webp.

2. apps/desktop/src/shared/hooks/useImageUpload.ts — The useImageUpload(sessionId) hook is the onImageUpload callback. It:

   • Reads the file as ArrayBuffer
   • Sends raw bytes + filename to the Rust backend via fsSyncCommands.attachmentSave(sessionId, data, filename)
   • Gets back { path, attachmentId } where path is the absolute filesystem path
   • Converts path to an asset protocol URL via convertFileSrc(path) from @tauri-apps/api/core
   • Returns { path, attachmentId, url } which the FileHandler extension uses to insert an image node with src: url

3. apps/desktop/src/session/components/note-input/raw.tsx — The RawEditor component wires up useImageUpload and passes fileHandlerConfig to the tiptap NoteEditor.

4. crates/fs-sync-core/src/lib.rs — attachment_save() stores files under <vault_base>/sessions/<session_id>/attachments/<filename> with dedup naming.

5. apps/desktop/src-tauri/tauri.conf.json — Asset protocol is enabled with scope ["**/*", "$APPDATA/**"]. No explicit CSP is configured.

Likely Root Cause(s)

Primary suspect: CSP blocking asset protocol URLs for images.

In Tauri v2, convertFileSrc(path) produces URLs like http://asset.localhost/<encoded_path>. No explicit CSP (content-security-policy) is set in tauri.conf.json or in the Rust backend (src-tauri/src/lib.rs). Tauri v2 auto-generates a default CSP, but depending on the version, the default may not include http://asset.localhost in the img-src directive. This would explain both symptoms:

• Pasted images → "invisible box with dots": The image node is correctly created in ProseMirror, but the browser refuses to load the src URL due to CSP → broken image placeholder.
• Dragged images → "large white space": Same root cause, but the node occupies block-level space with no visible fallback.

Secondary concern: Markdown round-trip loses image data.

When sessions are persisted:

• Save: raw_md (tiptap JSON string) → json2md() → markdown file (_memo.md)
• Load: markdown → md2json() → tiptap JSON → raw_md

The attachmentId custom attribute is lost in this round-trip since @tiptap/markdown's MarkdownManager doesn't use the custom parseMarkdown/renderMarkdown properties defined on AttachmentImage (they're static properties, not part of the markdown serializer spec). The src URL (an http://asset.localhost/... URL) does survive the markdown round-trip as a standard ![](url), so images would still display if the asset protocol URL is loadable.

However, http://asset.localhost/<path> URLs are session-specific absolute paths. If the vault location changes or the app is reinstalled, these URLs would break permanently since there's no attachmentId→path re-resolution on load.

Relevant Git History

• 338f06bf7 — feat: save image attachments to session folder instead of base64 (#3315) — Introduced useImageUpload and the attachment save flow. Before this, images were stored as base64 data URLs inline.
• 399992123 — refactor(tiptap): switch to official @tiptap/extension-image with block-level images (#3321) — Switched to official @tiptap/extension-image.
• 0f7ca99ea (branch devin/1772014304-resizable-image) — feat: bring resizable image back to editor — Unmerged PR adding resize support (related to the "nice-to-have" in this issue).

Version Note

@tiptap/markdown is pinned at 3.17.1 while all other tiptap packages use ^3.19.0. This mismatch is worth noting but likely unrelated to the display issue.

Suggested Investigation / Fix Approaches

1. Add explicit CSP in tauri.conf.json with img-src 'self' http://asset.localhost asset: blob: data: to ensure asset protocol images are allowed. This is the most likely fix.

2. Add image re-resolution on load: When loading raw_md, scan for image nodes and re-resolve src URLs using convertFileSrc() based on the attachmentId attribute (or extract the filename from the existing URL). This would fix both the CSP issue and make images resilient to vault location changes.

3. Verify in browser devtools: The quickest way to confirm the CSP theory is to open the Tauri webview devtools and check the console for CSP violation errors when pasting an image.

Key Files

File	Role
packages/tiptap/src/shared/extensions/index.ts	Image extension + FileHandler config
apps/desktop/src/shared/hooks/useImageUpload.ts	Image upload hook
apps/desktop/src/session/components/note-input/raw.tsx	Memo editor wiring
crates/fs-sync-core/src/lib.rs	Attachment storage backend
apps/desktop/src-tauri/tauri.conf.json	Asset protocol + security config
packages/tiptap/src/shared/utils.ts	json2md / md2json round-trip
apps/desktop/src/store/tinybase/persister/session/save/note.ts	Memo persistence (save)
apps/desktop/src/store/tinybase/persister/session/load/note.ts	Memo persistence (load)