Inline images in the composer: put the picture in the message, not under it

[typedev]

What I'd like to be able to do

Put a picture in the message, where it belongs in the text, instead of hanging it off the bottom as an attachment. Write a paragraph, paste a screenshot, write the next paragraph — and have the recipient read it in that order.

Apple Mail and Outlook have done this for years, and people who move to Vireo from them notice its absence quickly: the only way to send an image today is to attach it, which turns "here is what I mean" into "open the second file to see what I mean".

This is a real change in how the composer behaves, and the right shape for it is your call — I'm describing what I found in the code rather than proposing a finished design.

Where the code stands today

Everything needed is already present; what's missing is the path between the pieces.

The editor can hold it. src/ui/rich_editor.rs is a WebKit view with a contenteditable body. It already intercepts paste (PASTE_SCRIPT, to linkify plain-text URLs) and already hands the document back as document.body.innerHTML. It has no image insertion of any kind — not from the clipboard, not by drag and drop, not from a file chooser.

The reader already does the inverse. inline_cid_images in src/worker.rs rewrites cid: references to data: URIs when displaying a message, precisely so inline images from other clients render. Vireo can read this shape; it just can't write it.

lettre already speaks it. MultiPart::related() and Attachment::new_inline_with_name(content_id, name) are both available in the pinned version. The send path in build_email currently composes a flat multipart/mixed with Attachment::new(name), so every file goes out as a declared attachment.

One way to implement it

The part I find appealing here is that the bytes never need a new channel between the web view and Rust — they can ride inside the HTML the composer already returns.

1. Capture, in the existing paste handler. When the clipboard carries an image, read it as a data: URI and insertHTML an <img src="data:…"> at the cursor. The same handler body serves a drop listener.

2. Convert, when the message is built. Walk the outgoing HTML, lift each data: URI out into its own part, and replace the reference with cid:<generated>.

3. Emit the shape.

multipart/mixed
├── multipart/related
│   ├── multipart/alternative  (plain, html)
│   └── inline parts, one per embedded image  (Content-ID, disposition inline)
└── ordinary attachments

Why the disposition matters here

Inline parts go out as Content-Disposition: inline, which keeps them out of the recipient's attachment list — they are already drawn in the body, and listing them again would be noise. That is the same distinction extract_attachments leans on to keep a newsletter's cid: logo out of the file list, so a message composed this way stays consistent with how Vireo already reads other clients' mail.

Questions I'd want your view on before anyone writes it

• Entry points. Clipboard paste and drag-and-drop are the ones muscle memory expects. A toolbar button with a file chooser is a third — worth having, or clutter next to the existing attach button?
• Size. Embedding is base64, so it inflates by a third and the whole thing sits in the editor's DOM while composing. Is there a ceiling past which a file should become an ordinary attachment instead, with a word to the user?
• Scaling. A modern phone screenshot is several thousand pixels wide. Downscale on insert, insert full size and constrain with CSS, or leave it alone?
• The plain-text alternative. The text/plain half of the alternative cannot show a picture. Silently omit it, or leave a marker where the image was?
• Editing. Once inserted, should an image be resizable or removable as an object, or is it just content the caret moves over?

Happy to prototype whichever shape you'd prefer, or to leave it entirely with you — this one changes the feel of the composer, so it seemed better to ask than to arrive with a finished patch.

[hyprlab]

Excellent idea, working on integrating this now

[hyprlab]

Shipped in stable 1.20.0, out now. Thank you for the proposal and the detail in it, @typedev. What landed: paste or drop a picture and it goes into the text at the caret, scaled down to 1600px and kept within the writing width; sending lifts each one into an inline cid: part inside multipart/related, so it is not in the recipient's attachment list. A click selects an image whole so delete, cut and copy act on it, and the right-click menu offers "Send as Attachment Instead". One thing worth knowing from the implementation: WebKitGTK's native image paste arrives as a blob: URL that clipboardData never sees, so every blob: image is adopted into a data: URI the moment it appears in the document. Update with flatpak update.