Closed Bug 310948 Opened 19 years ago Closed 16 years ago

[Mac] Cannot paste image from clipboard into new message

Categories

(Thunderbird :: Message Compose Window, defect)

PowerPC
macOS
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: craig.upton, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20050930 Camino/1.0a1+
Build Identifier: version 1.5 Beta 2 (20051002)

On OS X (10.4.2) I cannot past an image from the clipboard into a new message.
The paste option is not grayed out, it just will not paste. This works in Windows.

Reproducible: Always

Steps to Reproduce:
1. Compose a new Message
2. Take an image that that is in the clipboard. (ctrl+command+shift+4 to select
a portion of your screen to do a screen grab)
3. Try and paste into the new message window

Actual Results:  
Nothing happens.

Expected Results:  
The image from the clipboard should be pasted into the new message window
I would dupe this as bug 223909, but that's Windows-only apparently.
After update to beta 1.5 my gif and jpeg inline images will not showup in field
of message text area, just red outline where it should be. Also, attached images
and or other files pdf etc, a dialouge box pop up and claims that it cannot
download to a particular file folder. The work around for that is to drag the
attacched file out of the message into a folder [it will not drag to desktop].
This works 65% of the time. thanks
jakmart@comcast.net
mac OS 10.3.9   [G4+cable]
Confirming based on multiple reports.  I don't see bugs for any product (including Core and Toolkit) about image-paste support for Mac; this is 
probably a more general bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Cannot paste image from clipboard into new message → [Mac] Cannot paste image from clipboard into new message
This doesn't work on Linux either.  What is the corresponding Linux bug #?
In my system, I can reproduce what appears to be the same problem, as follows:

a) open a new compose window in HTML format;
b) drag-and-drop one or more image files into the message body; the images are correctly inserted;
c) save the message (e.g. by pressing Ctrl+s or by waiting until auto-save happens);
d) drag-and-drop one or more image files into the message body again; the images are not correctly inserted, only the "empty box pictured with a red dot in it" appears.

I'm using TB 1.5.0.4 on XP and this happens on POP, IMAP, and newsgroup accounts. I tested with JPEG files under 100 KB. 

The main work-around I use is obviously to paste all the necessary images before saving the message for the first time (and also before auto-save happens). Once all the images are correctly pasted, it's possible to compose the message and save it as needed without any problem. If I happen to need to paste additional images after having saved the message, the work-around is to save the message again (just in case), close the compose window, go to the Drafts folder, reopen the message, and paste the new images before further savings.
(In reply to comment #5)

No, these are two seperate bugs we are dealing with here.

I can reproduce the original 'Mac' bug (no copy/paste of an image/no error), but CANNOT reproduce the 'bug' as reported by Telmo Amaral
QA Contact: message-compose
in bug #392491, josh points out:

From Cocoa widget nsCliboard.mm (line wrapping change for bugzilla):

/*
  if (flavorStr.EqualsLiteral(kPNGImageMime)  ||
      flavorStr.EqualsLiteral(kJPEGImageMime) ||
      flavorStr.EqualsLiteral(kGIFImageMime)) {
    // We have never supported this on Mac OS X,
    // we could someday but nobody does this.
      break;
  }
*/

about the "nobody does this", I'm not sure that still applies.  on mac os x, pasting images into notepad like text editor supports this, and other applications might as well.
also, see Bug 223909 and Bug 47838.
I can't find the corresponding linux bug number soo here goes...

Running in KDE 3.5. kernel 2.6.21.5-smp
Ksnapshot can copy an image to the clipboard, which can then be pasted into other applications (e.g. Kmail), but not Tbird.

User-Agent: Thunderbird 2.0.0.9 (X11/20071031)
reproducible: always

further details -- if there is pre-existing text in the clipboard (which can be pasted into tbird), the clipboard is emptied by the act of copying the image from ksnapshot to the clipboard.  In other words, the text that was on the clipboard is erased, and nothing is pastable in tbird.  

I've also just confirmed the bug in tbird 2.0.0.4 on Mac OSX 10.4.11

<RANT>
It's hard to believe this bug is related to bug 47838, which has been unsolved for *over 7 years* and applies to an all-but-dead backwater (i.e. mozilla suite). The bug has been fixed in Tbird 2 for windows for some time.

I can't tell you how incredibly disappointing it is to find that the bug exists at all in 'nix versions of the same generation.
</RANT>
The linux issue should be resolved with bug 21747/bug 412196.

xref bug 79864.
Assignee: mscott → nobody
I am using Mac OS X tiger latest updates.  I thought that TB latest worked fine pasting images into the HTML compose window.  Well, since upgrading to Firefox 3.01 I can not paste images into TB no matter the source.  When I select the paste function, nothing is pasted.  I can't believe this problem is not getting more attention.
Still happening - Mac OS X 10.5.4, TB version 2.0.0.16 (20080707). 

Images will not paste from Mac clipboard into TB e-mail message body, neither with edit/paste (which is black, not gray, showing TB recognized that something's in the clipboard) nor with cmd-V. Image paste from clipboard works in OS X Mail and all other Mac apps I've tried (OO3, TextEdit, GIMP).

Plain text from the clipboard pastes into TB message body just fine.
Just upgraded my MacBook to Leopard (Mac OS X 10.5) and still can not paste images into a Thunderbird HTML Compose Window's message body.
I just tried out 3.0 Alpha 2 on Mac OS X 10.5.4. It still does not work. I think this is related to Firefox bugs 428096 and 79864.
Roger Peters: what does Firefox have to do with Thunderbird?  I thought on Mac OS X they share no code...
You're misinformed then. A great deal of the code is shared, certainly things like clipboard operations are.
Is this still an issue? The code referred to in comment #8 has been updated by bug 393646 (checked in Sep 17, 2007), and bug 428096 (pushed Nov 07, 2008) is fixed as well. The unit tests of bug 444800 have a "pass" on pasting for both JPEG and PNG from the Mac clipboard. Can somebody check on a 3.0b1pre nightly?
Blocks: 344248
2008.11.14 - just checked 3.0b1pre nightly (shredder.app) on Mac OS X 10.5.5. I opened a JPEG in Preview, did a select all, then a copy. Flipped over to Mozilla 3 and pasted the image into a new message. SUCCESS! Sent image to myself. Opened sent mail in SENT folder. Image appeared fine, in-line. Quit shredder, opened T-bird version 2.0.0.17 (20080914) and opened the message in the SENT folder and the image appeared fine, in-line. 

Looks like it might be fixed. Someone else should confirm, please.
Thanks, great. If somebody could confirm that pasting of PNG works as well and sends the image in PNG format, we could verify bug 344248 in the process.
Is a 2nd independent confirmation needed or should this just be resolved WFM?
Paul also confirmed PNG pasting in the other bug, thus I closed that one.
Melchert (per Wayne's recommendation), can you make the official assessment whether or not this can be considered fixed? See bug 384116 comment #25 on pasting in different encoding flavors using "clipboard.paste_image_type".
Keywords: qawanted
Whiteboard: [resolved by other bugs?]
2008.1.22 Tested in Mac OS X 10.5.6 build 9G55; TB version 3.0b1 - WORKS!

I dragged a png photo from my desktop into the body of a message. Picture showed up in the body fine, sent fine, showed up in Yahoo mail fine. I opened the mail in the sent folder and the photo was there. I exported the mail as eml and the photo was there. Seems to be fixed.

Question: If the photo is inline, there will be no attachment paperclip that shows in the message list, correct? Hope so, because no paperclip shows next to the tested mail in the message list. Ship it!
I can confirm that this is fixed on
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090128 Shredder/3.0b2pre
and
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.2a1pre) Gecko/20090127 Thunderbird/3.1a1pre

With clipboard.paste_image_typ=1 I dragged an JPEG image into an HTML message and sended it to myself. The picture in the incoming message has the MIME type "png". Than I changed clipboard.paste_image_typ to 0 and did the same thing again. Now the MIME type of the image was JPEG.
Thanks, closing this WFM per comment #20 and comment #25 (Nomis101 confirmed by private message that indeed copy-and-paste was used, not drag-and-drop which is based on a different mechanism).

The issue of not being able to paste an image from the clipboard at all on OSX reported here initially should be resolved now, please open a new follow-up bug with specifics if something else still causes problems on that platform.

-> WFM (resolved by fixes for other bugs)
Status: NEW → RESOLVED
Closed: 16 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
Whiteboard: [resolved by other bugs?]
I am still having this issue, using Thunderbird 2.0.0.19 (20081209) for Mac and do not believe it is resolved.

I can drag a image from the desktop into a message window. The image will then appear.

However, I cannot drag an image from Firefox (3.0.8 Mac Intel OSX 10.5) into the message. Nor can I copy an image from any source (including Firefox) and paste it into the image, as I can on TB for Windows.

If I copy an image from Firefox, and paste it into TB, the URL of the image appears, instead of the image itself.
(In reply to comment #27)
> I am still having this issue, using Thunderbird 2.0.0.19 (20081209) for Mac 

This is *not* fixed for any 2.0.0.x release (and likely won't be).
This should be fixed for 3.0 beta 2 and nightly builds.
You need to log in before you can comment on or make changes to this bug.