User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2b5) Gecko/20091204 Firefox/3.6b5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091223 Shredder/3.1a1pre Thunderbird does not copy an image to clipboard using mouse context menu Reproducible: Always Steps to Reproduce: 1. Copy an image into the clipboard using an image editor such as Paint, Paint.NET, etc. 2. Click to write a new message in Thunderbird 3. Paste the image 4. Thunderbird will paste the image 5. Click on the image using the mouse right button. A menu appears. 6. Click on "Copy" 7. Try to paste the image into an image editor such as Paint/Paint.net Actual Results: No image is pasted into the image editor because there is no image in the clipboard. This only happens when composing a new message. When reading, Thunderbird copy the images to the clipboard. Expected Results: The image should be pasted correctly.
Does this work on 3.0 ? Any error message in Tools -> Error console ? can you copy paste iamges from Firefox 3.6/3.7 to paint ?
Ludovic, It does not work on 3.0 either. There is no message in Tools-> Error console. Yes, I paste image from FF to paint.
One more thing I forgot to ask , do you also have the issue when Thunderbird is started in -safe-mode(http://kb.mozillazine.org/Safe_mode) ?
Yes, it happens. It is a bug easily to be reproduced
I do see it also.
This works for messages displayed but not for those which are currently composed. The issue is mitigated on trunk now by pasting "data:" URIs for images instead, but if the receiving application doesn't understand such URIs, it won't paste either. Also, using "Edit As New" brings up "mailbox:" URIs which aren't understood outside the context of Thunderbird or SeaMonkey either. The solution would be for the editor to also put the pixel data of the image onto the clipboard as is already done for display. Thus, moving to Editor.
Also confirmed on Linux current trunk nightly, "Copy Image" on a displayed message puts a Bitmap onto the clipboard, "Copy" in the editor doesn't.
A mailbox: URL is not meaningful anywhere except in Thunderbird. It is not the responsibility of the editor to make this work.
Ok, thanks. Thus whatever was done in the display-message code needs to be ported to the compose-message end, though I think that it's just using cmd_copyImage there without having any MailNews-specific implementation...
Ehsan, on a 2nd thought I'm confused though anyway. When composing a message or reopening "as new", the image is shown in the editor also for "mailbox:" and "imap:" URIs. Thus, the pixel data must be available to the editor code as such but isn't put onto the clipboard. I've tested with a "data:" URI as well and it won't put a respective Bitmap representation on the clipboard even though cmd_copyImage does (applies to both MailNews Composition and SM Composer, the latter clearly being separated from any mailbox specifics). So, I still think that Editor should have the data necessary to produce a Bitmap flavor on the clipboard, maybe it's just something done wrong when invoking it from MailNews or Composer which would put it there. Do you get a Bitmap copied onto the clipboard for an <IMG SRC="data:..."> when using the Editor and right-click > Copy within the context of Firefox?
I'm not sure what you mean by pixel data. The editor doesn't care about the contents of images at all. In fact, it does not even implement the copy functionality (that's implemented half in content and half in widget). Judging from my knowledge about the editor code base, I don't think that it's relevant at all. I think the best thing to do here is to debug and see what's really wrong!
Environment: Win 7 home premium SP1, Tbird 45.2.0 My experience is, "Copy Image" while reading a message, does NOT copy image to Windows clipboard. Also, when composing an image, you can copy WITHIN Tbird (e.g., from a received message to a draft), but if you then use context menu on image in draft, Tbird once again fails to put image on Windows clipboard. IMHO this is a somewhat weird interpretation of "Copy." Thank you.