557708 - Drag and drop of images from Firefox to Thunderbird as attachment results in BMP conversion, fails when sending

Status: NEW

(Core :: Widget: Win32, defect, P5)

Description

[rsx11m]

Using Firefox 3.0.19 and earlier, when viewing an image in the browser
(right-click, View Image), then drag-and-drop it into the attachment pane, would result in Thunderbird downloading the original file from the server. Doing the same from 3.6.3 on Windows, a static copy is attached in bulky BMP format (thus, without any compression whatsoever). This is also the case for drag-and-drop from Firefox 3.6.3 to SeaMonkey 2.1a1pre, and from SeaMonkey 2.1a1pre to Thunderbird 3.0.4. Drag-and-drop from browser to composition windows within SeaMonkey 2.1a1pre results in the desired behavior of the original being attached. Also, drag-and-drop into an HTML composition produces a link to the original and "attach this image" set by default, thus also downloading the original.

If the behavior was changed on purpose and for a good reason, at least a more mail-friendly PNG format should be chosen, or the clipboard.paste_image_type preference observed. I'm filing this for MailNews Core first, but this may need to go into Core Widgets: Win32 if it's a general clipboard issue.

> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a4pre) Gecko/20100406 SeaMonkey/2.1a1pre

Comment 1

[rsx11m]

I'm unable to reproduce this on Linux, thus it appears to be primarily an issue with the Windows widgets. Since no comments from MailNews came in, I'm moving this bug respectively.

Comment 2

[rsx11m]

I've retested this with more recent builds and see a different behavior now on builds from 5.0 and 6.0:

> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a2) Gecko/20110703 SeaMonkey/2.3a2

Drag and drop of an image from the 6.0 browser into the 5.0 attachment pane still creates a random BMP attachment and even reports the correct size when attaching, but upon sending or saving as draft, I'm now getting "Unable to open temporary file [attachment location]. Check your 'Temporary Directory' setting."

The behavior between Firefox 3.6.18 and Thunderbird 5.0 is unchanged, thus the temporary file created by the browser apparently is now deleted immediately in Gecko 6.0 after the reference is passed on to the mail/news application.

Comment 3

[Brian R. Bondy [:bbondy]]

This page describes some image clipboard formats:
msdn.microsoft.com/en-us/library/aa359736(v=vs.85).aspx

In particular we could support when we "Copy Image" we add to the clipboard:
CFSTR_MIME_X_PNG  (TEXT("image/x-png"))


We would then need to post a different task for Thunderbird to use this new clipboard format instead though.

Comment 4

[Joris Debonnet]

This just happened to me, when I dragged a 64 kB jpg from Firefox 20.0.1 into an email in Thunderbird 21.0b1 which produced a 2.4MB email due to having converted the image into bmp. I don't remember having had this problem before, but clearly whatever the issue is, it's still there!

As the OP says, it would probably be a great idea to start with to default to PNG24 instead of defaulting to BMP. But the most ideal would of course be if the original compression could be kept, if that is possible. 

This is the image that I dragged from FF into TB, so that you can test with the same conditions: 
http://images3.wikia.nocookie.net/__cb20121116012752/disney/images/d/d0/Ponyo004.jpg

Comment 5

[rsx11m]

I'm not sure if the original image format is still available (it would be if a reference is passed over the clipboard rather than the image bitmap data itself, but then you may run into problems with Thunderbird having to download the data on its own, potentially not being aware of the correct context that Firefox had).

As far as I know, pixel data is transferred as "Device Independent Bitmap" on Windows, which corresponds to the BMP file format. However, when pasting an image into the editor, it will be converted to either PNG (default) or JPEG, depending on the setting of the clipboard.paste_image_type preference, to compress the image.

Comment 6

[Joris Debonnet]

Thanks for the explanation. 

My clipboard.paste_image_type is 1 (which means prefering PNG > JPG > GIF). But here are three use-cases that result in three different image types: 

(1) When I copy-and-paste a selection of bitmap data from an image editor, Thunderbird does compress it in the PNG format. So the setting works correctly for pasting pure bitmap data from the clipboard.

(2) But when I drag-and-drop the image from FF into TB, it is inserted as BMP. No compression algorithm is selected. 

(3) But, interestingly, when I right-click and copy that same image in FF, and then paste in TB, it attaches the original file with the orginal filename and compression. What happens is it creates an image with the image URL, an "Attach this image" turned on.

So it seems there's a difference between drag-and-drop and copy-and-paste. Only drag-and-drop has this issue: it's as if the selection of a compression algorithm is skipped in this case. I guess the question is: what exactly happens when dropping an image into the Editor? I doesn't "copy-paste" the original image (as in (3)), and it doesn't paste pure bitmap data (as in (1)). I think I understand that it doesn't do (3), but it should at least do (1) then. (2) should never happen :)

Comment 7

[Joris Debonnet]

Interestingly, when I drag-drop an image together with some text surrounding it, it copies the original HTML and so the original image is attached (as in case (3)). The issue only occurs when only the image itself is dragged and dropped.

Comment 8

[rsx11m]

(In reply to Joris Debonnet from comment #6)
> (3) But, interestingly, when I right-click and copy that same image in FF,
> and then paste in TB, it attaches the original file with the orginal
> filename and compression. What happens is it creates an image with the image
> URL, an "Attach this image" turned on.

This version actually copy-pastes HTML code with an <img src="http://..."> reference to the original location, then Thunderbird downloads and attaches it. No recoding is performed in this way. Copy-pasting in case (1) transfers the actual pixel data, hence the DIB -> PNG recoding.

My initial observation for opening this bug was recoding of the image to BMP when drag-and-drop into the attachment pane (i.e., not into the message itself) was performed, but maybe case (2) runs into the same issue for drag-and-drop into the message itself.

Comment 9

[Joris Debonnet]

Aha, I see. I was wondering whether I should open a new bug, but I guess it sounds like it's the same: dropping bitmap data into the message or attachment pane works as expected, but dropping an actual image from a webpage in Firefox does not.

Interestingly, the issue only occurs as discussed when dragging from Firefox. When I drag-drop from IE8/9/10, it attaches the image from its cache (good!), and when I drag-drop from Google Chrome it works when dragging into the attachment pane (with a bad filename and no file size info, but it works), though it fails miserably when dragging into the message (it inserts a string of Asian characters instead). 

In any case, Firefox seems to be the only one that drags that bitmap format around with no better alternative attached. Chrome and IE try delivering the original file before they would default to delivering the bitmap data. (I may be wording this in a strange way, but you get what I mean)

Regardless, Thunderbird should handle that 'dropped' bitmap data the same way it would handle 'pasted' bitmap data. I just mentioned the above because perhaps it's Firefox that does something really weird with the data, confusing Thunderbird into believing it's already in a good format. Or something.

Comment 10

[rsx11m]

Similar report in bug 871873 - dragging JPG image into TB compose window inserts as inline BMP.

Comment 11

[rsx11m]

See bug 871873 comment #7 and following for more analysis. It appears that this bug here is caused at the source application, whereas the other bug reflects a change in drag-and-drop behavior on the receiving end.

Comment 12

[[e-mail]]

This is a repost from a different thread. The information is relative to this issue and <A HREF="https://bugzilla.mozilla.org/show_bug.cgi?id=871873">bug 871873</A>, so I'm adding it to both these threads:

Firefox 24

Steps to reproduce:

drag & drop
From Firefox, drag an image from a web page to a Windows Explorer window

Doing so copies the selected image to the Windows Explorer folder, but ALSO creates a .BMP bitmap copy in C:\Documents and Settings\UserName\Local Settings\Temp

So many of the comments below describe similar or the same behavior, dragging-dropping from Firefox to Thunderbird, however it should be helpful to know it also occurs by dragging from Firefox to Windows Explorer (and the Desktop)

Shout-out of thanks to @rsx11m

Until this is corrected, I've just had to make a .BATch file to DEL them

Comment 13

[rsx11m]

Yet another flavor of this bug: Using drag-and-drop of an image from the website from Firefox (24 ESR) into a SeaMonkey build (2.27a2) creates a data: URI which is incomplete and lacks the type of the image ("data:<junk>;base64,<encoding>" where <junk> may be empty or an arbitrary string). When saving the message as draft, it gets attached as "text/plain" which doesn't make much sense.

No messages in the error console. This was tested on Windows 7.

Comment 14

[Thomas D. (:thomas8)]

(In reply to Brian R. Bondy [:bbondy] from comment #3)
> In particular we could support when we "Copy Image" we add to the clipboard:
> CFSTR_MIME_X_PNG  (TEXT("image/x-png"))
> We would then need to post a different [bug] for Thunderbird to use this new
> clipboard format instead though.

If I understand informed comment 3 correctly, this bug actually starts in FF which does not preserve enough clipboard data to allow pasting in a better format than bmp (or even the original image format).

Does FF still have this lack? (clipboard inspection of copied-from-FF image.png/jpg needed)
If yes, do we have a FF bug for that?

Comment 15

[neilkakkar]

Hello!
Could someone please guide me along what needs to be done here?
I'm new, and looking for a bug to tackle!
Thank you!

Comment 16

[Mike Hoye [:mhoye]]

Ni, Neil - sorry for not getting back to you sooner, are you still interested in this bug?

Comment 17

[Piervincenzo Parisi [:PierV]]

Hello,
I would like to give it a try. It would be my first contribution ever, so I will probably need a special guidance from you mentor guys. :)

Comment 18

[neilkakkar]

Hey Mike! Likewise.

I have my exams right now, I'd need 10 days before I can work on this.
Thanks!

Comment 19

[Sreekar]

Hey Mike,
Is the bug resolved yet? If not, I would like to try and fix this bug. Although I'm a new contributor, I am prepared to work on this, for however long it takes.

Comment 20

[Brian R. Bondy [:bbondy]]

Thanks Sreekar, I assigned the bug to you. 

I haven't worked on this code in a while but some good starting points would be to set breakpoints in `widget/windows/nsClipboard.cpp`, `widget/windows/nsImageClipboard.cpp`, and `widget/windows/nsDataObj.cpp` to learn the code around there.

Comment 21

[arni2033]

Just in case nobody has tested other applications:
This also happens in Skype - it can't transfer image if I drag-n-drop it from Firefox to Skype
Also, bug 1191462 states that conversion to BMP is unwanted. Somehow, I agree with that.

Comment 22

[rsx11m]

Sreekar, are you still working on this?

Comment 23

[Petter Österlund]

Variation on this bug or other; Windows7, Open a BMP file using Windows Photo Viewer (the default), copy image. Paste image into compose window of Thunderbird (now using 38.5.1) along with some other text. Send it.

It will look fine in Thunderbird but not at all in e.g. Outlook or Outlook web client. The problem is that the encoded attachment is text/plain and apparently at least Outlook fails to view this inline attachment using "<img src="cid:[e-mail]" alt=""> while Thunderbird seems to bypass the faulty content-type.
 

Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: base64
Content-ID: <[e-mail]>

Comment 25

[rsx11m]

(In reply to rsx11m from comment #22)
> Sreekar, are you still working on this?

Apparently not, thus unassigning...

Comment 26

[jbonnafo]

Hello,

I would like to work on this issue.
Could you please assign it to me ?

Thanks,

Comment 27

[jbonnafo]

Hello,

I have reproduced the case described using firefox nighly build on my machine (Windows 10) and Thunderbird 45. When i drag & drop an image loaded in FF to Thunderbird, it creates a "big" BMP file.

In debug mode the call stack shows:

nsImageToClipboard::CreateFromImage
line 127 is called by:
nsDataObj::GetDib
line 853

if i understand well the code:
nsresult
nsImageToClipboard::CreateFromImage ( imgIContainer* inImage, HANDLE* outBitmap )

always create BMP files.

Should the logic be changed in nsDataObj::GetDib ?

Thanks,

Comment 28

[jbonnafo]

Hello,

in:

nsImageToClipboard::CreateFromImage ( imgIContainer* inImage, HANDLE* outBitmap )

line 146 seems to force the creation of a bitmap file:

nsCOMPtr<imgIEncoder> encoder = do_CreateInstance("@mozilla.org/image/encoder;2?type=image/bmp", &rv);

Should this be changed or made more flexible ?

Thanks,

Comment 29

[jbonnafo]

Hello,

just as a test, a have replaced the line :
nsCOMPtr<imgIEncoder> encoder = do_CreateInstance("@mozilla.org/image/encoder;2?type=image/bmp", &rv);
by
nsCOMPtr<imgIEncoder> encoder = do_CreateInstance("@mozilla.org/image/encoder;2?type=image/jpeg", &rv);

I am not claiming this is the solution but with this, locally built FF was able, withthe described Drag and Drop, to create an email attachment with a JPEG instead a BMP.

I would like to have your opinion on this in order to move forward for this issue.

Thanks,

Comment 30

[jbonnafo]

Hello, 

This is in fact quite complex:

We can have the BMP built through the
nsImageToClipboard::CreateFromImage called by nsDataObj::GetDib method
but there is also another code path leading to a temporary BMP file:
nsDataObj::DropImage
This method also calls nsImageToClipboard::CreateFromImage and tries to dump the generated BMP file into the temp folder.

I would like to get some help / advise on how to fix this.

Thanks,

Comment 31

[jbonnafo]

Attachment: bug557708-v1.patch

Hello,

This is a first patch proposal: I tried to get rid of the BMP generation and amended the GetDib method to use the image flavor in order to handle JPEG/PNG/GIF/BMP formats.

I have unit tested this code with TB 45.5.1 on Windows 10.
I have noticed that the attachments remain with they original format but that TB states it is a "portion of embedded message".

Thanks,

Comment 32

[Thomas D. (:thomas8)]

Wayne, Jörg, can you pls ensure or cc others to ensure that Jeanluc gets enough assistance/attention/direction/reviews here so that we can succeed to take this promising patch through.
There's also an assigned mentor, Jim Mathies [:jimm], thank you for mentoring and please come forward ;) Tia.

Comment 33

[Jorg K (CEST = GMT+2)]

This is M-C code in widget/windows. TB's knowledge (and review permission) doesn't reach there. I can tell you however, that the patch contains a lot of trailing spaces that the reviewer will complain about ;-)

Comment 34

[jbonnafo]

Hello,

I am happy to remove the trailing spaces. 
Would you mind giving me one example in the patch i have submitted ?

Thanks,

Comment 35

[Jorg K (CEST = GMT+2)]

Click on "Splinter Review" above and you'll see them all. Surely you can also detect them in the patch you uploaded using the editor of your choice. In Notepad++ on Windows I search for the regular expression | $| (of course without the |, so space dollar) to find spaces at the end of the line.

Comment 36

[jbonnafo]

Attachment: bug557708-v2.patch

Hello,

This is a second patch proposal: I tried to get rid of the BMP generation and amended the GetDib method to use the image flavor in order to handle JPEG/PNG/GIF/BMP formats.

I have removed all trailing spaces in the 3 files i have amended.

I have unit tested this code with TB 45.5.1 on Windows 10.
I have noticed that the attachments remain with they original format but that TB states it is a "portion of embedded message".

Thanks,

Comment 37

[Jorg K (CEST = GMT+2)]

I think you misunderstood. The idea was not to remove all trailing spaces in the files you touch, since that generates many changes, but not to add new trailing spaces with your patch. If you have a look at your now superseded first patch, there were some trailing spaces added where there weren't any before and also where you made real changes.

Applying "boy scout rules" (that is, leaving the camp site cleaner than you found it) is appreciated by some reviewers but not all, since it increases the changes to be reviewed.

Comment 38

[jbonnafo]

Hello Jorg,

We are right, i had misunderstood the comment. I was under the impression that it was mandatory to remove all trailing spaces in files (.h / .cpp) before submitting a patch.

Would you like me to revert my V2 patch and prepare a V3 removing trailing spaces only for code i have amended ?

Thanks,

Comment 39

[Jorg K (CEST = GMT+2)]

Yes. Best use v1 to start. You can actually remove trailing spaces directly in the patch file in the lines being added, the ones which have a +. Editing patches can be tricky, you need to remember that the first column is one of - + or space.

Since you have
-
+(space space)
you will need to refresh straight after applying the modified patch since this group will be removed upon refresh.

Do check the patch before resubmitting it.

Comment 40

[jbonnafo]

Attachment: bug557708-v3.patch

Amended V1 patch proposal to remove trailing spaces only on code i have amended.

Thanks

Comment 41

[Jorg K (CEST = GMT+2)]

Comment on attachment 8822073 [details] [diff] [review]
bug557708-v3.patch

Review of attachment 8822073 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry to be so picky. Only lines that were changed should be in the patch.

::: widget/windows/nsDataObj.cpp
@@ +1450,5 @@
>    nsresult rv;
>    if (!mCachedTempFile) {
>      uint32_t len = 0;
>      nsCOMPtr<nsISupports> genericDataWrapper;
> +

What's the change here?

You edited the patch, but didn't apply and refresh it since that would have removed this "non-change".

Comment 42

[jbonnafo]

Hello,

No problem.
Could you please provide me a link to a manual that would explain how to perform the "apply and refresh" actions described in your comment ?

Thanks,

Comment 43

[Jorg K (CEST = GMT+2)]

Hmm, that really depends on your workflow and how you created the patch in the first place. I'm using mercurial queues (which are deprecated, so I shouldn't advertise this), and there the commands are:
hg qnew, hg qpop, hg qpush and hg qref. Some use TortoiseHg. There are many ways to skin a cat here, but having changes in your patch which aren't real is not well regarded ;-)

Comment 44

[jbonnafo]

Attachment: bug557708-v4.patch

Proposed patch version 4, regenerated patch file from Mercurial command, trying to get rid of trailing spaces.

Comment 45

[jbonnafo]

Hello,

Could you please tell me if the proposed patch is a good candidate to solve this issue ?

Thanks,

Comment 46

[:aceman]

Thanks for looking into this.
Sorry, I'm not on Windows to be able to test the patch. As said, we will need gecko-core people to look at the proposal. Looks like you have already found a good candidate.

Comment 47

[jbonnafo]

Hello,

Who should i contact in order to get some feedback on this patch proposal ?

Thanks,

Comment 48

[Wayne Mery (:wsmwk)]

(In reply to jbonnafo from comment #47)
> Who should i contact in order to get some feedback on this patch proposal ?

jimm just hasn't reviewed it yet. Unless he has someone else in mind

Comment 49

[Jim Mathies [:jimm]]

Comment on attachment 8822080 [details] [diff] [review]
bug557708-v4.patch

Review of attachment 8822080 [details] [diff] [review]:
-----------------------------------------------------------------

minor nits here. I need to do some manual testing and push to try as well.

::: widget/windows/nsDataObj.cpp
@@ +1367,5 @@
>    m_enumFE->Reset();
>    while (NOERROR == m_enumFE->Next(1, &fe, &count)
>      && dfInx < mDataFlavors.Length()) {
> +      if (mDataFlavors[dfInx].EqualsLiteral(kNativeImageMime) ||
> +          mDataFlavors[dfInx].EqualsLiteral(kFileMime))

You should remove the kFileMime check below this, it's redundant.

::: widget/windows/nsImageClipboard.cpp
@@ +162,5 @@
> +      encoderCID.Append(bmpString);
> +    }
> +
> +    nsCOMPtr<imgIEncoder> encoder = do_CreateInstance(encoderCID.get(), &rv);
> +    //nsCOMPtr<imgIEncoder> encoder = do_CreateInstance("@mozilla.org/image/encoder;2?type=image/bmp", &rv);

nit, remove this code.

Comment 50

[Jim Mathies [:jimm]]

also if you wouldn't mind, please merge this with tip. My fault in that the review took so long. unfortunately tb patches fall to the bottom of the todo list these days.

Comment 51

[jbonnafo]

Hello,
Thanks for the code review, i will amend files accordingly a submit a new proposal.
Thanks,

Comment 52

[jbonnafo]

"please merge this with tip", Could somebody tell me what this means ?

Comment 53

[Jorg K (CEST = GMT+2)]

Sure. As the codebase at Mozilla changes quickly, the patch most likely doesn't apply any more, some say "it has bit-rot" or "it bit-rotted". So the patch needs to be rebased on the latest version of the underlying files, which is the "tip" or "default". Sorry about the jargon ;-(

Comment 54

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.

Comment 55

[Wayne Mery (:wsmwk)]

jbonnafo has suggested he will look at updating the patch

Comment 57

[BugBot [:suhaib / :marco/ :calixte]]

This good-first-bug hasn't had any activity for 2 months, it is automatically unassigned.
For more information, please visit auto_nag documentation.

Comment 58

[Mike Kaganski]

Note that copying e.g. https://bug-attachments.documentfoundation.org/attachment.cgi?id=178031 to Windows clipboard uses a temporary JPG file, and dragging it to another application uses a BMP; both they use CF_HDROP clipboard format for the transfer that refers to the temporary file, so there seems to be different code paths here that account for this unfortunate difference.

The actual creation of the temporary BMP in the filesystem happens inside IDataObject::GetData call, with FORMATETC referring to CF_HDROP. So there should be something in the DnD data OLE object implementation if FF that is responsible for that.

The patches from jbonnafo looked to touch related area (even though they were adding unneeded breaks in switch after return statement, and so on).

Comment 59

[Mike Kaganski]

nsDataObj::GetFile, that gets called for CF_HDROP, iterates through mDataFlavors; and it stops on whatever one of the three types it finds first:

• application/x-moz-nativeimage -> DropImage
• application/x-moz-file -> DropFile
• application/x-moz-file-promise -> DropTempFile

In case of copy to clipboard, mDataFlavors has:

• text/html
• text/html
• text/_moz_htmlinfo
• text/_moz_htmlcontext
• application/x-moz-file-promise-url
• application/x-moz-file-promise-dest-filename
• application/x-moz-file-promise
• application/x-moz-file-promise
• application/x-moz-nativeimage
• application/x-moz-nativeimage
• application/x-moz-nativeimage

So in this case, DropTempFile gets called for item 6.

In case of drag-n-drop, it has:

• text/x-moz-url
• text/x-moz-url
• text/x-moz-url
• text/x-moz-url
• text/x-moz-url
• text/x-moz-url
• text/x-moz-url-data
• text/x-moz-url-desc
• application/x-moz-custom-clipdata
• text/_moz_htmlcontext
• text/_moz_htmlinfo
• text/html
• text/html
• text/unicode
• text/plain
• application/x-moz-nativeimage
• application/x-moz-nativeimage
• application/x-moz-nativeimage
• application/x-moz-file-promise
• application/x-moz-file-promise
• application/x-moz-file-promise-url
• application/x-moz-file-promise-dest-filename

and DropImage gets called for item 15.

A simple fix could be converting the single loop in nsDataObj::GetFile into three separate loops, first one checking for x-moz-file-promise, then for the rest two. That is in case the calls to m_enumFE methods actually do something (I do not see what can they be useful for, actually, but I digress), otherwise one loop could store less preferred index, and keep searching until it finished the loop or found most preferred case, then perform the call corresponding to the found most preferred case.

But I do not know if x-moz-file-promise is actually preferable over x-moz-nativeimage. Is the elements order in mDataFlavors important? Why are there duplicates?

Comment 60

[Mike Kaganski]

Attachment: Bug 557708 - Prefer DropFile* to DropImage for CF_HDROP. r?[e-mail]

DropImage changes image type to BMP unconditionally, which makes
it undesirable for drag-and-drop operations. Only call it when
the flavor list doesn't have the other two options.

Also remove calls to m_enumFE->Reset and m_enumFE->Next, since
their results are unused in the processing here.

Comment 61

[BugBot [:suhaib / :marco/ :calixte]]

This good-first-bug hasn't had any activity for 2 months, it is automatically unassigned.
For more information, please visit auto_nag documentation.

Comment 62

[BugBot [:suhaib / :marco/ :calixte]]

This good-first-bug hasn't had any activity for 2 months, it is automatically unassigned.
For more information, please visit auto_nag documentation.

Comment 63

[Stephen A Pohl [:spohl]]

N-i for the review of the attached patch.

Comment 64

[David Parks [:handyman]]

The patch itself looks pretty good but we want to settle bug 1765222 first as this makes assumptions that it would guarantee.

Comment 65

[jake]

(In reply to David Parks [:handyman] from comment #64)

The patch itself looks pretty good but we want to settle bug 1765222 first as this makes assumptions that it would guarantee.

You mean the proposed fix for this bug 557708 relies on bug 1765222 being fixed. It's obvious when you think about it; I'm just clarifying what you mean by "this".

Comment 66

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 67

[Eric Auld]

Hello, is this bug still available? If it is, I will look into it, and once I grasp what's involved, I'll ask it to be assigned to me.

Comment 68

[Sylvain Spinelli]

Yes this annoying bug is still available on Windows!

Comment 69

[Dina Maharani]

When dragging and dropping images from Firefox to Thunderbird as attachments, it seems that the images are being converted to BMP format, and the sending process fails. This issue can be quite frustrating.

There are a few potential solutions to this problem:

Change the image format: Before dragging and dropping the image, try converting it to a different format, such as JPEG or PNG, using an image editing software or online converter. Then, attempt to drag and drop the converted image into Thunderbird and see if the sending process is successful.

Use the "Attach File" option: Instead of relying on the drag and drop method, use the "Attach File" option in Thunderbird to manually select the images you want to attach. This way, you can bypass the conversion issue and ensure that the images are attached in their original format.

Update Firefox and Thunderbird: Ensure that you are using the latest versions of both Firefox and Thunderbird. Outdated software versions can sometimes cause compatibility issues. Check for updates and install them if available.

Check Thunderbird settings: Verify the settings in Thunderbird related to attachments. Go to the Thunderbird menu, select "Options" or "Preferences," and navigate to the "Composition" or "Attachments" section. Ensure that the default image format for attachments is set to a compatible format, such as JPEG or PNG.

If the issue persists after trying these solutions, it may be helpful to seek assistance from the official support channels of Mozilla (the organization behind Firefox and Thunderbird) or consult their community forums. They may have more specific troubleshooting steps or insights into this particular issue.

References: https://tafsiran.com/

Comment 70

[jake]

(In reply to Dina Maharani from comment #69)

This comment is spam. Could it be removed and the account deleted?

Comment 71

[Sara Mag]

When dragging and dropping images from Firefox to Thunderbird as attachments, it seems that the images are being converted to BMP format, and the sending process fails. This issue can be quite frustrating.

There are a few potential solutions to this problem:

Change the image format: Before dragging and dropping the image, try converting it to a different format, such as JPEG or PNG, using an image editing software or online converter. Then, attempt to drag and drop the converted image into Thunderbird and see if the sending process is successful.

Use the "Attach File" option: Instead of relying on the drag and drop method, use the "Attach File" option in Thunderbird to manually select the images you want to attach. This way, you can bypass the conversion issue and ensure that the images are attached in their original format.

Update Firefox and Thunderbird: Ensure that you are using the latest versions of both Firefox and Thunderbird. Outdated software versions can sometimes cause compatibility issues. Check for updates and install them if available.

Check Thunderbird settings: Verify the settings in Thunderbird related to attachments. Go to the Thunderbird menu, select "Options" or "Preferences," and navigate to the "Composition" or "Attachments" section. Ensure that the default image format for attachments is set to a compatible format, such as JPEG or PNG.

If the issue persists after trying these solutions, it may be helpful to seek assistance from the official support channels of Mozilla (the organization behind Firefox and Thunderbird) or consult their community forums. They may have more specific troubleshooting steps or insights into this particular issue.

References: https://asrmehr.ir

Comment 72

[jake]

[blah blather, so-called qualty content that Google likes]
[Rubbish that ChatGPT would generate]
References: https://link-to-malicious-url.example.org

Can we please delete these spam posts entirely, rather than just marking them as spam?

Keeping them on the system allows the spammers purpose to be served.

Can we also investigate where they are coming from, so as to prevent them? There is SpamCop, though large ISPs tend to ignore reports, even if (and particularly if) originating from their own customers.

This does not help this bug report. But we need to deal with the new phenomenon of "bug report spam".

Comment 73

[Mike Kaganski]

(In reply to David Parks [:handyman] from comment #64)

It's not encouraging to contribute to projects, where your commit is put on hold because of some improvement, that is not worked on for two years. Why would anyone try then?