1602445 - embedded Image in an HTML Email is removed when sending

Status: RESOLVED INVALID

(Thunderbird :: Untriaged, defect)

Description

[Int]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.99 Safari/537.36 Vivaldi/2.9.1705.41

Steps to reproduce:

I composed a HTML email and embedded an image in the body of the email

Actual results:

The embedded Image in the HTML Email was removed when sending the email.
The email arrived at the recipient without the image.
When saving the email as a draft the image is still present in the body.

Expected results:

Email should have been sent with the image

Comment 1

[Int]

This happened after upgrading to Version 68.3.0
In Version 68.2.2 this was still working as expected

Comment 2

[Int]

This happened after upgrading to Version 68.3.0
In Version 68.2.2 this was still working as expected

Comment 3

[Jorg K (CEST = GMT+2)]

Regression? Have you tested this? I'm 99.995% sure that this is more "forced plaintext chagrin" that our module owner didn't want to improve in bug 1222176 :-( - Users are still suffering in this area.

Comment 4

[Magnus Melin [:mkmelin]]

Reporter says it's a regression.
Hardly bug 1222176 though. If it's something old, then bug 180997.

Int: did the recipient have any special pref regarding message format? And were you able to reproduce a second time? I think we need more info.

Comment 5

[Jorg K (CEST = GMT+2)]

I think you'll find that the send option isn't at "Send the message in HTML anyway", but instead "Convert the message to plain text" (bug 1510134 comment #18). And there will be a recipient in there with "unknown" preference. At least that was the case in all the six bugs I've looked at so far (bug 1510134 and duplicates). And although I'm not 100% familiar with this, I believe that bug 1222176 was going to mitigate the problem. You may want to read bug 1516381 comment #11.

Comment 6

[Int]

Referencing bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1510134
gave me some hints were to look and I found that the recipient had set the option "prefers to receive messages formatted as plaintext".
This option in the address book was unknown to me so far.
When upgrading from Version 68.2.2 to Version 68.3.0 I also switched from a SOGo address book to a Nextcoud + fbsync provided address book, which changed the setting "prefers to receive messages formatted as" from Unkown to Plaintext on all address book entries.

Comment 7

[Magnus Melin [:mkmelin]]

If you can pin it down to SoGo, please report it to the add-on author. (When referencing bugs, please just type bug and the number. Bugzilla will do proper autolinking.)

Comment 8

[Thomas D. (:thomas8)]

(In reply to Magnus Melin [:mkmelin] from comment #7)

If you can pin it down to SoGo, please report it to the add-on author. (When referencing bugs, please just type bug and the number. Bugzilla will do proper autolinking.)

If this particular case was attributed to an addon changing the recipient-prefers preference to plaintext, how can it still be a regression of TB? Just because reporter says so?

Comment 9

[Magnus Melin [:mkmelin]]

The status, resolution, and keyword etc. fields are independent. It was reported as a regression in thunderbird, but turns out invalid. It's an invalid report of a regression.

Let's keep the meta for posterity. Maybe it was a regression in the add-on, who knows. It could be useful for add-on authors to query on regressions in their add-on. Thus, the whiteboard.

Comment 10

[Jorg K (CEST = GMT+2)]

That makes no sense. Then all bugs where non-updated add-ons damage TB functionality should have been marked as regression. We've never done that. Compare without regression keyword: https://mzl.la/35P6l86 (300) to with regression keyword: https://mzl.la/2PLv4oo (14).

Comment 11

[Magnus Melin [:mkmelin]]

Bugs should be marked as regressions from get-go if reported as such. What disadvantages would you see in that?
If not marked they easily slip through the cracks. Once the bug is resolved it doesn't make much difference what keywords it has.

Comment 12

[Jorg K (CEST = GMT+2)]

Looks like Thomas and I are of the opinion that we only track regressions for our own software, not add-ons affecting it. The keyword description is even more restrictive: https://bugzilla.mozilla.org/describekeywords.cgi

As the comparison of 300 to 14 shows, what you are promoting here is not the common way we have worked so far, and a brief spot check of those 14 bugs showed that you yourself set the regression keyword on most of them (as far as I looked).

Looks like you're triaging more bugs than before and apply your "Magnus-only" rules. So be it then.

Comment 13

[Magnus Melin [:mkmelin]]

I've always pushed for people to do that. The lack of regression marking on bugs reported as such is hurting the triage process IMHO.

Comment 14

[Jorg K (CEST = GMT+2)]

I agree that when we read "worked in version xx.x, doesn't work in yy.y", the alarm bells should come on. Those bugs should be marked regressions so we can find and fix them in C-C or M-C. If the malfunction is caused by an add-on and the bug is invalid, I see no necessity for tracking it as a regression. As you said, for a resolved bug the keyword doesn't matter and I highly doubt that add-on authors come here to look for regressions in their software.

Comment 15

[Int]

Maybe you should open a new ticket for your discussion about the usage of the keyword regression? :)