1679518 - Pasting an image from browser into composition silently defaults to linking and *not* attaching the inline image to the message

Status: NEW

(MailNews Core :: Composition, defect, P2)

Description

[Ben Bucksch (:BenB)]

Reproduction:

1. Click [Write] to create a new email
2. Go to Firefix, right-click on an image, and select "Copy image" from the context menu, to copy the image file itself, not just the URL.
3. In the Thunderbird email editor, paste.
   => You see the image (not just the link) inline in the email body
4. Send
5. In the Thunderbird inbox of the recipient, open the email

Actual result:

• The image is not visible
• You see the alt text instead
• This is presuming the default settings where external image loading is disabled, for privacy reasons
• In other words, the recipient does not see the email correctly as the sender intended. The sender clearly intended the image to be inline.

Expected result:

• The image is displaying inline in the message, in the same way in which the sender was seeing it.
• This works even with external image loading disabled, e.g. the image needs to be attached to the email.

Workaround:

• After step 3, double-click on the image to see the properties. Check the checkbox
  [x] Attach this image to the message

Fix:
This option needs to be turned on by default.

Rationale:

• The user specifically pasted the image contents, not just the link.
• External image loading is very dangerous for privacy and is disabled in Thunderbird for very good reasons. (Otherwise very spammer could track whether you are receiving and reading his spam, and send you more. Also, senders can track the time and place then I read the email.)
• Therefore, we need to support privacy-aware email reading. That requires that embedded images are attached and not just linked.

Comment 1

[Magnus Melin [:mkmelin]]

I don't think so. It needlessly increases the mail size by a lot, and especially for a mail thread where it gets duplicated over and over again, that's not very nice.

In the actual results, you actually get a banner allowing you to click to see the picture. If it's from someone you know, there's not too much privacy problems with clicking that (unlikely to be a tracker, and even if it would be "you saw my mail" is not very privacy concerning at that stage)

Comment 2

[Ben Bucksch (:BenB)]

Well, the image was important. That's why I explicitly included it. I would agree with you for signatures. Not for images I intentionally embed.

We actually don't do want the user told us here. The user wanted the recipient to see the image inline in the mail. We don't do that. Even if both users are using Thunderbird. It looks right before sending, and then is wrong after sending. We failt the user.

you actually get a banner allowing you to click to see the picture

I actually don't. I never ever want remote images.

Comment 3

[Ben Bucksch (:BenB)]

This is simply a bug, because the received mail does not match the sent mail.

Comment 4

[Thomas D. (:thomas8)]

I've been bitten by this, and I agree with Ben that the current UX is wrong in many ways.

• ux-wysiwyg: from an unsuspecting user's perspective, composed message (showing perfectly embedded inline image) is radically different from just linking up the image online. More so as pasting really feels like embedding the actual image, not just a link, and there's no indication about just linking.
• ux-consistency: When dragging an online image to composition via Insert inline, it does get attached to the message, but not when pasting - but in both cases, it looks the same in the UI. This is inconsistent and increases the surprise/error factor for the different behaviour of paste. The end result should not depend on the method used.
• ux-error-prevention, ux-mode-error: It follows from the above wrt ux-wysiwyg and ux-consistency that users have all reason to be in false security that the actual image data has been attached to the message. The UI is in a different state than expected. This error should be prevented.
• privacy: Sender unknowingly exposes the recipient to privacy leaks. These may be minor, but as a matter of fact the websites where the image was copied from will now also get some information when the recipient accesses the online image from the message received.
• dataloss: The worst problem here is the potential for full dataloss of the image data - if for whatever reason the original online source takes down or even just relocates the image on their server, the image will no longer be available in the message (especially for the recipient). This may happen sooner or later, and constitutes real dataloss because it's unexpected, inconsistent, and not communicated in any discoverable way that we're just linking, but not actually embedding the pasted image.
• As for the "message size" argument, size-aware users can always uncheck [x] Attach this image to the message, or even just send only the link. Imo the above UX problems outweigh this, especially dataloss. If anything, that's an argument for exposing the image flavor to users and give them a discoverable choice.

Suggested fix

• For a fast fix, I suggest that we make the default behaviour of pasting an image the same as dropping aka "inserting" an image inline - [x] Attach this image to the message should be checked by default.
• If we have more time, we could explore having some visual overlay icon in composition which indicates whether the image is linked or attached to the message and provides users with an easy and discoverable way of changing the flavor.

Implementation hints

• For the "fast fix" described above, it's enough to set the moz-do-not-send attribute to true on the <img> when it gets pasted. I don't know how hard that would be, maybe it's platform code.

Alex, would you be OK with the suggested "fast fix" of making the behaviours between paste image and drop image ("insert inline") the same, i.e. to enable Attach this image to the message also for the paste case?

Comment 5

[Alessandro Castellani [:aleca]]

Improvements to the Compose unfortunately are not part of this cycle.
I'd suggest to set this as lower priority and leave it open for later, or if some community member wants to tackle it.

In general, copying and pasting an image from the web is a very common and expected behavior from any modern wysiwyg editor, so we should definitely support it.

Not many resources for this right now >_>