Test this: in a bug-form's comment field: -type something - a few lines -select it -copy it -try to paste it into the same form again Result: you can't - nor can it be pasted into anything else i've found. getting heaps of " Transferable didn't support data flavor text/unicode (type = 220) Transferable didn't support data flavor text/unicode (type = 476) Transferable didn't support data flavor text/unicodode (type = 475) Test 2: Select text from a webpage in browser Place cursor at end of some text in a comment-form like this Paste This "kind" of text will paste OK, but the insertion point you had selected with cursor will NOT be the one used - the pasted text lands somewhere else. FWIW: I also get quite a lot of crashes these days while writing in bug-forms, Not 100% reproducable, but when it crashes, it's using the backspace that triggers it. Mentioning this since it CAN be related to the insertion point being messed up.

reassigning as per request

Accepting. Anyone know when this regressed?

And additional observation regarding the text copied from forms: It won't paste into composer either, but when attempting that, instead of the "untransferrable" error, i get this funny output in console: ->>>>>>>>>>>>>> Read Clipboard from memory ->>>>>>>>>>>>>> Write Clipboard to memory A paste should hardly WRITE to memory?? -- Additional observations - perhaps worth a new bug..i'm an ugly expert at bug-morphing... There are yet two anomalies in the forms: 1: They seem to honor two different font-sizes (??) - the indication: When i type in something and then click arrow down and then back again, the corsor will appear in a higher position on the line than what it was before. An additional arrow back will "lower" the cursor again, to be lined up with the text. 2: When i navigate with cursors in a form, it also skips one line if i navigate up/down with arrows, and it skips one character if i navigate back/forward on the line. (in middle of some text.) Makes it a little quirky to delete a character etc. because it will delete the "wrong" character first - i end up *having* to delete more than intended, thus also having to rewrite more than intended. No BIG deal but very "buggy".

i think it appeared around 3 days ago, but not certain. Currently using linux 2000-071910

Wait, too many bugs in one report! I'm taking the first one, that if you copy from a text control, you can't paste back into it, or into anything else. The second one, that the insert point gets confused, is a separate bug: if this is a middle-mouse paste, I can look at it, if this is a menu or key-binding paste, then it sounds like an edit rules problem, so try filing a bug to jfrancis. Arrow keys going twice as far as they should is bug 45390. I wasn't seeing it at all until today, and now I'm seeing it sporadically, and if someone could find a way to reproduce it reliably on today's build, it would be MUCH appreciated by everyone concerned.

I have no idea how this got marked resolved/fixed -- I marked it accepted. I'm having a LOT of problems using mozilla to do bugzilla stuff today. :-( Aha. The problem happens when the selection includes the end of a line. That narrows the problem considerably.

This is major dogfood. I just spent way too long retyping a bugzilla summary from another bug because I couldn't copy it out of the textarea. You have to be able to copy from textareas.

"confused insertion point" happen on middle-button pastes. As for wrong resolution on the bug: I may have caused that. According to bugzilla i "crashed" your first comment here (accepting). Had already written so much, so without being able to copy it i took my chances. I thought it went OK since i actually could see your comment. I didn't check if the crash had performed other mishaps - lesson learned.

Putting on [dogfood-] radar. Not critical to everyday use. Also, adding "nsbeta3" keyword for fix consideration in PR3. Is this a dup of other bugs? PDT thinks this has been a problem for a while. Does cut and paste not work in other areas? Would you pull pr2 off the wire for this.

Yes, I would pull it off the wire for this. Being able to copy multiple lines is fundamental to using bugzilla, webmail or any other service that uses textareas. Requesting reconsideration.

Turns out this is a selection regression. If I break in clipboard code and look at the XIF, it tells the story. When only part of a line is selected, the XIF looks like this (I've added newlines after the \n for easier reading, wish I could make this textarea not wrap): <?xml version=\"1.0\"?>\n<!DOCTYPE xif>\n <encode selection=\"1\"/>\n <section>\n<section_head>\n<document_info charset=\"ISO-8859-1\" uri=\"http://bugzilla.mozilla.org/show_bug.cgi?id=45996\"/>\n</section_head>\n <section_body>\n <markup_declaration><content>DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2 Final//EN\"</content>\n </markup_declaration>\n <content>;jf kls</content>\n </section_body>\n </section>\n When it's a multi-line, the XIF looks like this: <?xml version=\"1.0\"?>\n<!DOCTYPE xif>\n <encode selection=\"1\"/>\n <section>\n<section_head>\n <document_info charset=\"ISO-8859-1\" uri=\"http://bugzilla.mozilla.org/show_bug.cgi?id=45996\"/>\n </section_head>\n <section_body>\n <markup_declaration><content>DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2 Final//EN\"</content>\n </markup_declaration>\n <container isa=\"textarea\"><attr name=\"wrap\" value=\"HARD\"/>\n <attr name=\"name\" value=\"comment\"/>\n <attr name=\"rows\" value=\"5\"/>\n <attr name=\"cols\" value=\"80\"/>\n </container><!--textarea-->\n </section_body>\n</section>\n In other words, a selection spanning multiple lines inside a textarea expands to contain the text area itself, but none of its contents. Calling Mike in on the action to see if knows what might have changed.

Mike found a fix. This was an ender lite problem in the document's output to XIF: there was an optimization in place for a selection within the same text node, but when a selection spanned different text nodes across a br, the optimization didn't kick in and the root element was wrong. The fix is to to check whether the parents of the nodes are equal if the nodes themselves aren't equal.

Putting on [nsbeta2+][dogfood-] radar. Does not need a fix ASAP for daily work, but we should fix this for beta2. For fix in hand.

it was checked in. gracias

Hour Ifnye n stilleprode thisproble ease open itit yourcomnts. Hmurg f nyoecn sil eprouethisroblem, ease ropeni ithyourcmmts.Thsloos od on aHour Ifnye n stilleprode thisproble ease open itit yourcomnts. Hmurg f nyoecn sil eprouethisroblem, ease ropeni ithyourcmmts.Thsloos od on a

(not sure if last comment was a ViaVoice or Mozilla bug --- works fine pasting text from SimpleText) --- This looks good using today's builds on all platforms using original steps to reproduce. If anyone can still reproduce a problem here, please re-open. Thanks!