User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

On 91.0b6 - linux
Go to sent mail.
On a mail you have sent that includes inline images, right click "edit as new"

Actual results:

The compose window has frames for the images but no image content

Expected results:

The frames should contain the images.

Also happens on attempting to forward a sent mail.

Additional info that may be pertinent, mail boxes are IMAP, folders are not selected for offline use, images do show correctly in the sent mail messages.

Now on another machine, same OS, same 91.0b6 and inline images are included in mail forwarded/"edit as new" from sent mail.
Is there a setting in Thunderbird that could have flipped on one machine going from b5 to b6.

On the machine where Inline images do not show for "Edit as new" or in forward from sent mail, if on the same message in sent mail I click Reply, the images are shown in the compose window.

WFM.
Are you looking at the same emails? Maybe it's not inline but remote for one machine (and network or other issues)

The emails are hosted on Gmail with IMAP connection and no local "Offline" setting for the sent mail folder.
What makes me think it is a bug (or config. setting) is that the images are showing in the sent mail, if I "Reply" the email in the sent folder the images show in the compose window but if I "Forward" or "Edit as new" they do not show in the compose window.
So what is different about the way the compose window is created between Reply and Forward.

Apart from the images I have inserted inline in the original mail all the small images like logos in mail footers also fail to show in the same situations.

Note this was working without a problem until one of the updates to TB91.

Steve, It will be helpful to find the regression range using https://mozilla.github.io/mozregression/

Hi, Wayne. I may have more info I suspect is related. Now on TB92b2 where previously the compose window showed an empty frame it now has no frame or image. There are no warning messages in regards the missing content.
On Friday I was sending a bunch of emails with a couple of PDF attachments, one of these was changed out for each recipient. I was using Edit as New to save retyping the emails.
Lets say Email A is the first email I sent, emails B,C,D, etc. the subsequent ones. They all have PDF1 and PDF2, I change out PDF2.

1. I start by sending email A
2. In sent mail I right click email A, Edit as new, I change out PDF2 and recipient email address and send email B.
   All OK
3. In sent mail I right click email A, Edit as new, I change out PDF2 and recipient email address and send email C.
   I get an error "Sending of the message failed. The file PDF1 could not be found" Hovering over the file in the attachment pane it is file:///tmp/nsmail-66.pdf. Checking /tmp the file is not there.
4. I close the failed compose window, repeat 3. above and it all works OK.

Every second edit as new fails with the error message. Is there some /tmp flushing going on but then reloading again. Why every second time it is OK.

(In reply to Wayne Mery (:wsmwk) from comment #6)

Steve, It will be helpful to find the regression range using https://mozilla.github.io/mozregression/

I have run from January until current and all a good with this tool. I am assuming that the tool does not run with my current configuration profile, and hence is not checking against the updates as I have performed them to determine when the issue started. Is it possible to run the regression tool using my profile?

(In reply to Steve Edmonds from comment #8)

Is it possible to run the regression tool using my profile?

Yes. See https://mozilla.github.io/mozregression/documentation/usage.html

Wayne, I found on startup Thunderbird creates a link named lock in the profile. I.e. lock -> 127.0.0.1:+13463
This needed to be deleted to run mozregression.

I ran
./mozregression --app thunderbird --good 2021-01-05 --profile /home/steve/.thunderbird/frofile/ --profile-persistence clone-first

The problem exhibited in 86.0a1 when previously it didn't. In Help>about I was offered an update to 93.0a1 (21-08-25) which didn't exhibit the problem

I went back and started at --good 2021-08-10 93.0a1 (2021-08-10) (64-bit) which exhibits the problem

I then tried
./mozregression --find-fix --app thunderbird --bad 2021-08-10 --profile /home/steve/.thunderbird/frofile/ --profile-persistence clone-first
This loaded 93.0a1 (21-08-25) which didn't exhibit the problem, I entered "good" and then 93.0a1 (2021-08-10) was loaded which didn't exhibit the problem where when loaded first it does. I am assuming the profile is persistent during the mozregression session and loading 93.0a1 (21-08-25) somehow "Fixes" the profile so it then works with 93.0a1 (2021-08-10) that previously failed.

I have worked through daily releases of 93.0a1.
2021-08-23 has the issue.
2021-08-24 no release.
2021-08-24 the issue is resolved.

Sorry, typo. 2021-08-25 the issue is resolved.

Bug 1727164 fixed it?

Hmm, not sure the fix to that bug fixed my issue from the description. I am not attaching images from the web, just dragging and dropping from the file system or paste from the clipboard when I compose the initial email. The message in the sent folder that fails to include the image in the compose window when I try to forward it has the image base64 encoded in the email when it is in the sent folder.
I did find that 93.0a1 (2021-08-23) has the issue and 93.0a1 (2021-08-25) doesn't. I will do some more testing and see if the issue in comment is also resolved.

When 93.0a1 (2021-08-23) exhibits this bug, why does running 93.0a1 (2021-08-25) fix the bug so running 93.0a1 (2021-08-23) straight after does not have the bug.

"I will do some more testing and see if the issue in comment 7 is also resolved"

The pdf attaching issue of comment 7 is not resolved, but this inline image issue is so they are not related and the file attaching issue may need a new but report.

-> WFM then. Yes, that would need its own report.