**** observed with branch build 2000-10-11 ***** Text copied from the Subject field is pasted into the body as a quatation , it doesn happen if you copy/paste text into the body from the body Steps to reproduce: - compose a message: -highlight text in the Subject field; -copy the text (it doesn't matter whether you use Ctrl+C or copy commend from the menu); - paste the copied string into the body several times (again it doesn matter shortcut or menu is used); //note: the text is paste as a quatation, starting a new line every time you paste (it is tru for HTML and plain text)

I'm not seeing this with 2000-10-11-08 mn6 commercial branch build on NT 4.0. I've tried both menu and shortcuts. I've tried both html and plain text. I've tried both new message and replies. I've tried with auto-quoting pref on/off (thought this pref might be interfering). Will keep trying...any special characters in the subject?

laurel, are you selecting text in the subject and pasting it into the body? It doesn't happen when you copy/paste from body to body

Yes, from the subject line to the body. No quotation.

Peter Mock in our group just tried it on Win98, today's branch commercial build and had no problem in plain text or html. I just tried on linux, too and didn't have a problem.

I can reproduce the problem on my Win95-J using today's branch build.

I can reproduce it using today's linux branch build as well. I'm using RH6.2-J.

I don't see the problem using yesterday's branch builds.

maybe a side effect of the noxif landing. Reassign to jfrancis

My first thought was that it was a side-effect of our wrapping plaintext in a pre ... but then it would show up every time, not only occasionally. My new speculation is that this is a side effect of another problem we've had for a long time: if you have a quotation in the message, if you set the caret somewhere near there, it's easy to get into a state where if you type (and this would go for pasting as well), the text warps inside the quotation instead of outside. Marina, jj and others who are seeing this: do you have quoted text already in the body somewhere when you do this paste? E.g. are you doing a reply instead of a new message? Do you have a signature in the window?

my findings: - i am not talking about Reply (even though it shows up there as well), it is a specific pasting operation: from header into the body (from body to body everything is OK); - it's happening in Plain and HTML; - there is no dependency on a signature (happens with and w/o) and it is 100% reproducable

It isn't a quotation. It's wrapped in a pre. It is a (known) side effect of the noxif landing. There is a workaroun: you can backspace at the front of the preformmatted text to join it with the prior text. Or you can click in the text and choose "Body Text: from the paragraph format popup in the toolbar. I know how to fix this if it's an rtm issue: I just have to add a hint into the copy data that tells me the copy came from a text widget. Then in html paste, any paste data that came from a text widget will be retreived as plaintext instead of html. This will cause the data to not be wrapped in a pre once it is pasted in, but whiotespace will still be preserved becasue the plaintext serialize will have seen the pre when generating the plaintext version, and thus will preserve whitespace. Marking rtm in the hopes folks will tell me if I should implement this change now.

i have fix for this. We (jst, akkana, and i) forced text widget copy data to be wrapped in a <pre> so that whitespace would not be compressed by the serializer, etc.. That's the good effect. The bad effect is that it the editor preserves the <pre> on paste (as it is designed to do) and that causes the paste to go into a seperate block. The solution is to use our newly acquired copy hints data to pass along the knowledge that this copy came from a widget. Editor then uses that fact to force a plaintext serialization of the copy data. Whitespace is preserved, newlines are converted to breaks, and everybody's happy. One hackish feature is that the </pre> at the end of the copy data forces the serializer to emit a newline. We shouldn't change the serializer here because ordinarily this is the right thing to do. So when the editor sees the copy hint informing it of a text widget copy, it strips off the trailing newline from the serialized string. I played around with various text widget, mail, and composer copies and pastes and had good results. Do we want this for rtm? It's not trivial, but it's not extensive either. One of those middle of the road patches.

cc'ing more editor folks.

simon, kin: ready to wlka ou through reviews.

Add rtm need info to status whiteboard since Joe is waiting for reviews.

*** Bug 56344 has been marked as a duplicate of this bug. ***

PDT marking [rtm-]. Easy workaround of selecting the pasted text and making it Body Text.

*** Bug 56872 has been marked as a duplicate of this bug. ***

moving to future since pdt deems it not rtm critical

*** Bug 57041 has been marked as a duplicate of this bug. ***

Can we get this into the trunk, please?!

moz 0.9

Suggest: OS=ALL since it also appears under Linux (see bug 57041)

The <pre> thing is also causing bug 55661. (jfrancis@netscape.com mentioned this in the first 10-13-00 comment.)

Ok, can someone explain to me why this bug with fix-in-hand has been pushed out to 0.9?

Do we all agree that the data is pasted as <pre>, not quotation (<blockquote type=cite>)? marina, is it that what you saw? Assuming "yes", and changing SUMMARY.

jfrancis, what happens if I paste into a multipline text field? The newlines are annoying there, too. What happens if I paste into an HTML-capable third-party app (on an OS that understands extended formats)?

One more comment (sorry for spamming): Why don't you get rid of the <pre> comletely and you covert the data into real HTML, like we do in the Mail Viewer for format=flowed msgs? There, we convert all but the last space in a row into |&nbsp;|s and newlines into |<br>|s. The only reason why you still see a fixed width font is that we explicitly force a monospace font (if the prefs says so, which it does by default). That way, you wouldn't have to special-case in the pasting code, but the copy code would "do the right thing".

Can we get a review, super review and module approval on this fix?

Ben, I think an even simpler solution might be to simply refuse to do html copy for plaintext editors, ie, just put the plaintext flavor on the clipboard.

the same reason as any other fix in hand bug that gets pushed out: Netscape Product Delivery Team made the call. I'm glad I don't have their job, it's custom made for pissing folks off.

> Ben, I think an even simpler solution might be to simply refuse to do html copy > for plaintext editors, ie, just put the plaintext flavor on the clipboard. Yes, that would be the best approach IMO. (I don't know, why I didn't have that idea myself - it is the obvious solution.)

Lots of people keep asking about this. We should release note it.

Adding to Composer section of RTM release notes.

*** Bug 59573 has been marked as a duplicate of this bug. ***

Nominate for nsbeta1 since it's very high on the list of annoying mozilla bugs that make me want to go back to 4.x.

i need to redo my fix for this, per my earlier comment, to the much simpler approach of simply forcing a plaintext serilization when copying text fields/ areas/other plaintext widgets.

*** Bug 55661 has been marked as a duplicate of this bug. ***

From bug 56661: This extra newline happens with *any* <pre> formatted text, or with text from any widgets (textareas, input boxes, or even the Location bar). It also happens if you are viewing a text/plain file in Mozilla. It might be worth changing the subject, and re-evaluating the priority of this bug, since it affects much more than just copying from Subject and pasting into Body.

*** Bug 66121 has been marked as a duplicate of this bug. ***

Replacing kristif with robinf on the cc: as Robin Foster-Clark is now the doc contact for Composer.

Changing summary according to Scott's comment to make things clearer (hopefully). BTW, the product here is MailNews, but this happens (also) in the browser. Is this bug still assigned to the right product/component?

MailNews/Composition is probably not really the best component for this, but changing component would change the Assigned To, and since jfrancis wrote the patch, we probably shouldn't do that. Unless jfrancis wants to make the change, and then re-assign the bug to himself. What's the holdup on this patch getting into the nightlies? It's a really irritating bug, and there's a fix for it . . .

my fix is not the right fix. i have to rework it. odds are late this week it will land.

Bug 55661 (dup of this bug) has a bunch of dups, and this bug also has a bunch of direct dups, so marking as mostfreq.

*** Bug 66968 has been marked as a duplicate of this bug. ***

*** Bug 67051 has been marked as a duplicate of this bug. ***

i've reworked my fix into a simpler one that simply forces copying from text widgets to do a plaintext copy. I need to add some code to also catch the case of copy from a fullblown plaintext editor. Copying from inside a <pre> in an html document (whether in an html editor or simply in the browser) is a tougher issue and will require investigation.

*** Bug 67686 has been marked as a duplicate of this bug. ***

fixed. text copied from text fields, text areas, and plaintext editors should now copy only as plaintext, instead of as html ina <pre>. Text that really is in an html <pre> will still copy as a pre block. We can open a seperate bug on this if people care about it... it will require a different fix.

While vfying, please make sure that the DUP busg are fixed, too, especially bug 55661.

bug 55561 is _not_ fixed (linux build from 2001-01-20-07 morning). Since copying from <pre> still adds newlines and plaintext files are displayed as <pre>..... jfrancis, it would be good to fix this for text in <pre> as well, since currently copying from plaintext files (eg RFCs) and bugzilla comments puts a newline at the end of copied text. Also, I still see the newline issue when copying from "view source". verifying fixed on linux for textareas, plaintext editors, and textfields. Should we just reopen bug 55561? Or file a new bug on the remaining work?

er, I meant bug 55661 is not fixed.

i've reopened (and renamed) 55661 to address remaining issue.

Hip hip hooray! Thanks!

linefeeds have now completely vanished when copying from a form. Related? (see bug 68166)

Also, cannot copy HTML tags from a form. Appeared around the time of this checkin (bug 68870)

Looks ok to me using apr17 ccommercial trunk build.

Hmm... This still happens, see bug 90932

Please reopen, this is a regression (read bug 90932). While you're at it, add keyword to list.

Works for me (in text fields and text controls, which is what this bug covers).