1355913 - image issues in drafts and templates

Status: RESOLVED INVALID

(Thunderbird :: Untriaged, defect)

Description

[Anje]

User Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170323110425

Steps to reproduce:

Images inserted in emails. (not attachments).
Insert > Image
click on 'Choose file' - chose images stored on my computer.
This shows as file:///C:/Users etc etc
'attach this image to the message' is selected.
Image displayed in preview
All seems perfect.
click on OK
Image inserted.

Save as a Draft or as Template.


Actual results:

Click on 'Drafts'
select email.
Email shows correctly in Message Pane.
Select to Edit.
Opens in new Write window.
only top half of the image is shown.
double click on image to get 'Image properties'
Note the black outline of image box shows correct size.
In Image Properties window:
Image Location is removed - not helpful when you may need to locate that place on computer.
file name is now some base64 jibber which for the user is totally meaningless.
eg: data:image/jpeg;filename=black_faced_spoonbills.JPG;base64,/9j/4.../yK0DcosJuQ4kbbszzhT29KrD5XQ==

Image shows only half of image - same as shown in email.
Save as draft and now only half of image is shown.
No error message etc.
Send an email; and only half of image is sent/displayed.

In second case regarding a template email.
I created the template email using Thunderbird Write - not from any addon.
The background was white with a top border image.
click on Template folder
select template email and all looks correct.
Double click to open in new Write message.
No image of any description.
TYpe anything in the blank composing area
Save as draft
check saved draft and it shows the background.
so background only shows when it is viewed in Drafts/Templates folder, but not visible if you select to EDit or EDit as new message. 

Send and border is shown in received mail - trouble is because it is not shown when composing you have no idea wether you are writing in the area of the border, so text is unreadible.

no error messages.

Note these types of drafts and templates were created some time ago and had worked perfectly ok up until downloaded version 52.0
Tried recreating again or similar and have same issues.




Expected results:

Images in inserted into emails and stored as drafts or templates for re-use should display any included images fully both in storage fodler and in new Write window.

'File Location' must show the file location so this can be verified - image not moved etc.

Tested all of this in Thunderbird Safe Mode with same results.
When 'Edit' or 'Edit as new message' image should fully display and correct file location must be shown.
These are NOT images downloaded from internet or stored on internet website.
All images are stored on my computer.

Send email to myself at different email address and image is only showing half of it.

So it is vital that I do not use Drafts or Templates with any images.
This is quite important as creating and saving drafts is not only set up as auto, (now forced to disable) but it is not useable if you insert an image. It will mess up images.

Comment 1

[Jorg K (CEST = GMT+2)]

Processing of file-based embedded images has changed in TB 52.
Any inserted image is immediately converted into a data: URL ("some base64 jibber").
There will be no discussion about this and this will not be reverted.
Drafts and templates created before need to be converted to the new scheme.

Refer to the release notes:
https://www.mozilla.org/en-US/thunderbird/52.0/releasenotes/
IMPORTANT: The way images are included in a compose window has changed. Images are now included as data URIs and not as references to parts of other messages or operating system files. This allows better interoperability with office packages such as MS Office or LibreOffice.

===

That said, you are also reporting that you insert an image and it's only half displayed. Is this reproducible? Can you please attach an image that shows this problem. Does it show with all images or only certain ones?

Comment 2

[Jorg K (CEST = GMT+2)]

I inserted a 7 MB image into a composition and it inserted fine.

Comment 3

[Anje]

Attachment: insert-image.jpg

one of three images.

Comment 4

[Anje]

Attachment: insert-image-open draft.jpg

second of three images showing issue with Insert > Image being altered after opening wht appears to be a good draft

Comment 5

[Anje]

Attachment: insert-image-save draft.jpg

three of three showing how newly saved draft now only shows half  of image.

Comment 6

[Jorg K (CEST = GMT+2)]

Sadly I found two problems: Bug 1356300 and bug 1356303.

If this
> Send email to myself at different email address and image is only showing half of it.
is still an issue, please open a new bug and give exact steps to reproduce and attach the image that fails.

I'm closing this bug as invalid since it's a mixed bag of valid and invalid issues.

Comment 7

[Jorg K (CEST = GMT+2)]

Thanks for reporting this, I've move the third issue into bug 1356306.

Comment 8

[Anje]

Attachment: insert-image-full size.jpg

final image was a check to see if the 'custom size /contrain was having an effect.
This uses full size of image, left side shows the image been cut off just below green fern.

This is fully reproducable on any image (jpg) of any size.

Comment 9

[Jorg K (CEST = GMT+2)]

Please continue to comment in bug 1356306.

Comment 10

[Anje]

re :'Any inserted image is immediately converted into a data: URL ("some base64 jibber").
There will be no discussion about this and this will not be reverted.'

Sorry, but there seems to be a misunderstanding on this.
I'm not suggesting the above needs to be reverted.

The current situation assumes:
a) the user really needs to see the data url shortened version.  
b) the user does not need to know the File location.  

Data url is not the file location and the user needs to know the file location as the data url is of no use in determining where that file was located on eg: my computer. 
Data url is of no use to the user even if it is used to improve the functionality or redress bugs.
But the user is loosing the information that is pertinent to them - the File location.

I'm suggesting that the 'File Location' information needs to be shown in the 'File Location' text box and the new data: URL ('base64 jibber') needs to be in another text box maybe called 'Data: URL' .

Comment 11

[Jorg K (CEST = GMT+2)]

Currently the exact file location is lost after converting the file content into a data: URL. Only the file name is maintained. If you look closely, the file name is actually shown in the data: URL. You could file an enhancement request to carry the location around, but I don't know how feasible that would be to implement.

Currently we're working with high pressure on the bugs you reported:
Bug 1356600, bug 1356306, bug 1356303 (you don't see since you can't insert on in the first place) and also bug 1356300. Some other user also discovered bug 1356245.

Comment 12

[Magnus Melin [:mkmelin]]

(In reply to Anje from comment #10)
> Data url is not the file location and the user needs to know the file
> location as the data url is of no use in determining where that file was
> located on eg: my computer. 

Having that location show is actually not that desired if you ask me. If you show that, you get into the situation (that we have with attachments, which have not yet been converted over to use data:), that you don't know if it was the snapshot version at the moment you attached it, or the up-to-date version. And if its the updated version, what if it was moved/renamed/deleted. It's better to just always use an instant snapshot and not give any other impressions. That's also what people are used to from web apps.

Comment 13

[Anje]

re :Having that location show is actually not that desired if you ask me.

Maybe you do not use images or lots of images, but assuming others do not use it because you do not make use of it, is not helpful.
I paint pictures and therefore have quite a few images, often similar or saved with same name, but in different sizes or edits in different folders.
Knowing the location is important to me and has been useful on a regular basis for years. 
It has already caused agravation and time wasting exercises. 
I suppose one option would be to create yet another special folder just to hold any image used in a signature or template in Thunderbird,so that I know which file was used, so I would know which to edit or not as the case may be.

Who would have known that what one person perceives as not very desirable is actually extremely useful to another and such decisions cam impact on workflow.