User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20100101 Firefox/14.0 Build ID: 20120628060610 Steps to reproduce: I clicked Reply to an existing Received email. As you can see in the attachment, I selected certain text I wished to place into another open email. I clicked Edit>Copy and then clicked Edit>Paste at an insertion point in the other email window. Actual results: No text was pasted. I then tried Edit>Cut, which removed the text in question, yet when I attempted to paste it, the text would not copy at the insertion point. The same text however did paste into an open TextEdit window. The pasted text retained its formatting attributes. However when I then recopied that text and pasted back into the desired Reply to email window, the text appeared, but with all colour or formatting attributes stripped out. Expected results: I should be able to cut or copy anything I like in Thunderbird, and paste it anywhere I like in Thunderbird, or elsewhere, with all the formatting features intact.

This text is clearly on the Clipboard, because it can be pasted into TextEdit, yet it refuses to paste into any open Message window in Thunderbird.

Derek, you want to paste into a composition window, right? Was that draft composition message open in it's own composition window when you failed to paste the text into it? (you cannot paste text into draft compositions viewed in message reader preview of main 3pane window, nor into any other existing messages viewed in message reader)

Thomas, I am typing into an open composition window raised to Reply to an existing email. While that window is open, I open another window in Thunderbird, copy the quoted part of the text, and then return to the Reply composition window and then attempt to paste. The text is there, because it pastes into other text application windows, but something is preventing it from going into the Reply to composition window.

This makes the webapp tests pass.

Comment on attachment 643896 [details] [diff] [review] Followup: Don't use "/" inside app names. Oops; wrong bug. Sorry!

anything in error console? does paste work if you have not yet typed anything into compose? does paste into subject work?

Derek, can you pls reply to comment 7? (In reply to Wayne Mery (:wsmwk) from comment #7) > anything in error console? > does paste work if you have not yet typed anything into compose? > does paste into subject work?

Apologies for being so slow to respond. Paste into Subject works. Irrelevant whether typed or not, but the bug depends on the following steps to reproduce: Start New email composition window While New composition window open, Reply To another pre-existing email Copy text from Reply To composition window Revert to New composition window Paste - result, nothing is pasted Go to MS Word and paste, and the clipboard that would not paste into the New composition window pastes. Copy the text from the MS Word window Revert once more to the TB New mail composition window Paste - the text is pasted, but without the original TB formatting

(In reply to Derek Williams from comment #9) > Apologies for being so slow to respond. We are very grateful for your response, and I concluded from your previous responses that it's worth waiting (rather than closing this as incomplete). > Paste into Subject works. > Irrelevant whether typed or not, but the bug depends on the following steps > to reproduce: > Start New email composition window > While New composition window open, Reply To another pre-existing email ...where the pre-existing email should be HTML format for successful reproduction. I could not reproduce with a reply to Plain Text (bugmail). > Copy text from Reply To composition window > Revert to New composition window > Paste - result, nothing is pasted > Go to MS Word and paste, and the clipboard that would not paste into the New > composition window pastes. > Copy the text from the MS Word window > Revert once more to the TB New mail composition window > Paste - the text is pasted, but without the original TB formatting Thanks Derek for providing detailed steps! Following steps exactly as above, I'm able to reproduce this -> confirming. I copied from a random HTML message which happend to contain a remote image and some nested tables, of which I copied not the whole structure, but just some parts. (Note to self: test message was "Re: Vertretungsstunden - praktische Materialien für die Sekundarstufe"). One strange thing I noticed is that when cursor is at first character of blank new composition (paste target), paragraph format claims to be "Preformat" but when I cursor right, cursor left, it changes to "Body text" (which is default). Suspected cause I suspect this might be some confusion between the two composition windows, which due to our overcome design are probably technically the same window. This is what I saw on Tools > Error Console: Timestamp: 03.09.2012 09:24:43 Warning: Expected color but found 'mixed'. Error in parsing value for 'background-color'. Declaration dropped. Source File: chrome://messenger/content/messengercompose/messengercompose.xul Line: 0 Not sure if that's related or not. Next Steps We need to create a reduced testcase msg (and possible reduced scenario) to narrow down the causes of this bug.

Below are contents of Error Console (after clearing console and repeating minimal steps to reproduce bug): Timestamp: 03/09/2012 17:21:30 Warning: XUL box for _moz_generated_content_before element contained an inline #text child, forcing all its children to be wrapped in a block. Source File: chrome://messenger/content/messenger.xul Line: 0 Timestamp: 03/09/2012 17:21:35 Warning: XUL box for _moz_generated_content_before element contained an inline #text child, forcing all its children to be wrapped in a block. Source File: chrome://global/content/bindings/toolbar.xml Line: 276 Timestamp: 03/09/2012 17:21:35 Warning: XUL box for _moz_generated_content_before element contained an inline #text child, forcing all its children to be wrapped in a block. Source File: chrome://global/content/bindings/toolbar.xml Line: 276 Timestamp: 03/09/2012 17:21:35 Warning: XUL box for _moz_generated_content_before element contained an inline #text child, forcing all its children to be wrapped in a block. Source File: chrome://global/content/bindings/toolbar.xml Line: 276 Timestamp: 03/09/2012 17:21:35 Warning: XUL box for _moz_generated_content_before element contained an inline #text child, forcing all its children to be wrapped in a block. Source File: chrome://global/content/bindings/toolbar.xml Line: 276 Timestamp: 03/09/2012 17:21:45 Warning: Expected colour but found 'mixed'. Error in parsing value for 'background-color'. Declaration dropped. Source File: chrome://messenger/content/messengercompose/messengercompose.xul Line: 0 www.o2broadband.o2.co.uk : server does not support RFC 5746, see CVE-2009-3555 www.o2broadband.o2.co.uk : server does not support RFC 5746, see CVE-2009-3555

This seems to work fine in current trunk: Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/18.0 Thunderbird/18.0a1 Later on today I can check in Earlybird and beta. So this would indicate some change in core code took care of this.

I'm sorry, but I'm unable to reproduce this on Winxp, Win7, on trunk, earlybird, Beta or even the ESR on Win2k. There must be some missing pref or operation element involved. I followed the steps to reproduce religiously. This was with a pop3 setup BTW, if it makes a difference.

Joe, can you try to reproduce this once again with refined steps below? (In reply to Joe Sabash from comment #13) > I'm sorry, but I'm unable to reproduce this on Winxp, Win7, on trunk, > earlybird, Beta or even the ESR on Win2k. There must be some missing pref or > operation element involved. I can reliably reproduce this on WinXP/Trunk 20121003030547 Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/18.0 Thunderbird/18.0a1 I'm pretty sure my Trunk setup has a clean profile. > I followed the steps to reproduce religiously. > This was with a pop3 setup BTW, if it makes a difference. OK, let's try again: STR 1) Start TB Trunk (opens on Inbox of POP3 account) 2) Ensure the following settings for the account's "Composition and Adressing" options (as they *might* be relevant): [x] Compose messages in HTML format [x] Automatically quote... reply above the quote ... signature below the quote [x] Include signature for replies (but no signature specified) Otherwise, I suppose I have default settings for font etc. 3) click "Write", enter subject: "Composition window 1", no body text required (so you have a blank composition with subject "Composition window 1") 4) Keep Composition window 1 open (just ignore it) and switch back to TB main 3pane window 5) Select a random *HTML* formatted message ("Sample HTML message") from POP3 inbox message list (important! this bug will *not* occur on plaintext messages) 6) Click "Reply" (important!), which opens "Write: Re: Sample HTML message" (Composition window 2) - caveat: copying from message reader will *not* reproduce this bug! 7) In Composition Window 2 created in step 6, do partial (!) selection of message body text (important! selecting the whole message body will *not* reproduce this bug) 8) Ctrl+C to copy partial selection of composition window 2 9) Switch back to Composition window 1 10) Place cursor at beginning of empty body of composition window 1 11) Ctrl+V to paste into composition window 1 Actual Result Nothing (clipboard has the right content, but it's not pasted into composition 1) Expected Result Paste clipboard content (partial body copied from composition 2) into composition 1 I think the interesting bit is step 7 where this bug occurs only for partial selection of body text from composition 2, but *not* for selecting *all* body text from composition 2. I conclude that's it's something about the structure of copied partial HTML which makes this fail. Joe, if you're still unable to reproduce following refined steps above, I'll provide a testcase msg so that we can copy exactly the same stuff in step 7.

(In reply to Thomas D. from comment #14) > Joe, can you try to reproduce this once again with refined steps below? > 7) In Composition Window 2 created in step 6, do partial (!) selection of > message body text (important! selecting the whole message body will *not* > reproduce this bug) More precisely, I did not type anything into composition 2, and I started my selection at the beginning of composition 2 (in the blank line where you could type your reply above the quote), selecting half-way down into the quoted message (ensure *not* to select the *entire* quoted message).

(In reply to Thomas D. from comment #15) > (In reply to Thomas D. from comment #14) > > Joe, can you try to reproduce this once again with refined steps below? > > 7) In Composition Window 2 created in step 6, do partial (!) selection of > > message body text (important! selecting the whole message body will *not* > > reproduce this bug) > > More precisely, I did not type anything into composition 2, and I started my > selection at the beginning of composition 2 (in the blank line where you > could type your reply above the quote), selecting half-way down into the > quoted message (ensure *not* to select the *entire* quoted message). Yep, it's important that you start your selection *outside* the quote, and select half-way down *into* the quote. The following type of selections will *not* reproduce this bug for me (i.e., the following selections will paste correctly): - partial selection *inside* the quote, or selecting the entire quote (*without* the reply header "On date, xyz wrote") - Ctrl+A to select entire body of composition 2 including the full quote

(In reply to Thomas D. from comment #16) > Yep, it's important that you start your selection *outside* the quote, and > select half-way down *into* the quote. ...as seen in reporter's original Screenshot 1 of attachment 639099 [details].

Difficult to repro, but with those excellent steps, it certainly does. And the attribution line ,which is actually something like: <div class="moz-cite-prefix">On 10/2/2012 10:15 AM, JoeS wrote:<br></div> must be included in the copy action. It looks like all the html tags are being sanitized out of the copy. (try a paste into the insert html window and view the result. The message that I choose was a complex one with style tags (msword crapola) xref bug 671320 is filed against style tag removal on paste. Possibly this is another case of unwanted sanitation. "What's good for the FF editor, is not necessarily good for TB"

(In reply to Joe Sabash from comment #18) > Difficult to repro, but with those excellent steps, it certainly does. :) - thanks for testing! > xref bug 671320 is filed against style tag removal on paste. > Possibly this is another case of unwanted sanitation. I tested that and it's not the case (there might be unwanted sanitation, but it's not the reason for this bug). This fails even for plain and simple HTML markup, and there's HTML flavor on the clipboard which looks OK to me. TB is just refusing to paste it into the first composition. Interestingly, "Paste without formatting" (text flavor) works for cases affected by this bug. Using Clipboard viewer (1), here's the HTML flavor on clipboard which fails to be pasted in TB's composition window 1: Version:0.9 StartHTML:00000120 EndHTML:00000431 StartFragment:00000154 EndFragment:00000395 SourceURL:about:blank <html><body> <!--StartFragment--><br> <div class="moz-cite-prefix">On 04.10.2012 14:19, Lingo4you Shop wrote:<br> </div> <blockquote cite="mid:1864146c7c72f9b4f128648df8d8dd6f@neo.lingo4u.de" type="cite"> <h2>ego4u Shop Bestellstatus</h2> <p></p> </blockquote> <!--EndFragment--> </body> </html> Are there any problems about this content? So why does this fail to be pasted in HTML flavor? (1) http://www.freeclipboardviewer.com

Bug 373374 has a very similar scenario. Bug 373374 Comment 4 also has some references to code where this may fail. It clearly fails on the receiving side of editor. So I think the cause of this bug is probably something like this: (Scott MacGregor from Bug 373374 comment #4) > The trunk builds fail to generate the dom fragment from the pasted text here: > > http://lxr.mozilla.org/mozilla/source/editor/libeditor/html/ > nsHTMLDataTransfer.cpp#2614 > > The branch builds fail here: > > http://mxr.mozilla.org/mozilla1.8/source/editor/libeditor/html/ > nsHTMLDataTransfer.cpp#340 > > But the real error is probably earlier on when we construct the dom nodes > for the paste fragment that leads us to run into an error here. Also similar: Bug 789569.