Often when I copy text (via draging with the left mouse button), a line feed is added. This is very annoying/embarassing/dangerous as the line feed at the end can cause the text to be sent prematurely and irreversably to a program or chat. Examples of this: URL: http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser At the bottom, the paragraph "Some fields initialized...". a) select "ome fields". Paste into an xterm. Everything is fine. b) select "Some fields" by starting your drag in the MIDDLE of the 'S'. A space is added before the two words when you paste. c) select "Some fields" by starting your drag to the left of the 'S'. A line feed is added before the two words when you paste. URL: http://www.mozilla.org/status/2001-12-06.html Scroll down to the bottom, under Charley. His last item. d) select "testing and". Paste into an xterm. Everything is fine. e) select "Help testing" by starting your drag in the MIDDLE of the 'H'. A '*' is added before the two words ("* " actually... "asterix space") which is FINE. However a line feed is added to the end of "* Help testing", which is NOT fine. In fact, if you were to paste this into a shell, you could easily delete a ton of files without a chance to edit it, as '*' is a wildcard. f) select the last line by starting your drag to the left, or by triple clicking, same bad result as in 'e' above. URL: same as above A little bit up, under Kathy, her last item. g) select "ve nsIDiskDocument". Here's what's pasted in an xterm, or a mozilla input box: * * ve nsIDiskDocument Yep! that's right! asterix linefeed linefeed space space space space asterix space and then the text you selected, and then ANOTHER linefeed. I assume the indentation and 2 asterix's are because it's a nested list. I've have this happen on many pages for some time now. Seems to be triggered when you have the end or beginning of section. Above tested with Linux 2001120606.

DOM to text conversion. There are other related bugs, but they all deal with copying from <pre>. Jeremy is not copying from <pre>

copy pasting a prepending asterisk when copying from lists is dup of bug 78676

--> peterv

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.

This does have 'nsbeta1', actually. Moving back. This (combined w/ 78676) makes copy miserable and unreliable. Honestly, it's major catfood for my situation, causing dataloss/embarassment in certain cases.

I see this sometimes on Windows as well. This is always annoying, sometimes embarrassing or even downright dangerous. More than once I have copied a file name from Mozilla, pasted into a terminal and the line feed in the paste started my CVS commit prematurely! Peter, do you have any ways of reproducing this? Tanu, do you have access to Linux (would be easiest to test I think)? Peter has quite a few bugs on his 1.0 list so if at all possible it would be great if you could reassign this to yourself.

--> Myself.

ADT3 per ADT triage.

Bug#75283 has partially solved this bug. From the initial bug report now "g" is the only reproducible step. I'm working on this part.

Looks like Serializer is exhibiting the expected behaviour. HTML itself has quite many new lines which are carried forward by parser. Opening the HTML page with "viewer.exe" -> Dump Content, displays lots of new lines. I get correct output(no extra new lines) on testing the similar cases of nested listing. Changing the component to Parser and reassigning to Harish.

This is not a parser problem. The buffer passed into the parser, by the serialzier, contains the extra newline/spaces. Looks like the serializer is somehow including the whitespace that's before the selection point. As the reporter described there is no problem if the selection point is not in the begining of the word. Back to Tanu.

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.

I don't see this problem any more. Probably it's fixed with the fix for 159615. Marking as Dupe of #159615. *** This bug has been marked as a duplicate of 159615 ***