when cutting & pasting text from a text (not html!) file to another application, a <newline> is also created.

what buildid does your build have?

so you're copying text from a browser window which has a foo.txt loaded into the content window? Or, your're copying text from a Composer window with a text file loaded? Or, you're copying text from a Composer window which has some plain text typed into the content area? Or, you're copying text from a plaintext email you're recieved? Or, you're copying text from a message compose window you've just typed palin text into? Reporter, please provide clear and specific steps to reproduce. Please also include the buildID you tested. Thank you for testing mozilla and reporting bugs.

my build has been 2000100409 ... I copy text from the browser to a different application. HTML is fine but plain text files ftp://ftp.dante.de/pub/tex/support/rmligs/README don't work. To reproduce it just load the file into your mozilla, mark some text with you left mouse button, paste it to a vi running in an xterm with your middle mouse button. Sorry I didn't add a full decription in the report but I thought this would be trivial to reproduce.

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

Confirming on linux cvs build 2000101321, this bug has been driving me crazy for a while now.

Forgot to click Confirm bug. :)

Steps to reproduce: Select text in urlbar. Paste it into an xterm, for example, and notice that there is a newline. I'm not sure which component this should go into.

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

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

I think this one is jfrancis (see #54851), duping my bug filed against him and another one. If not, pass it on...

The reporter said copy from a html file worked fine, but I see it doesn't work on Win98.

qa for selection is my friend blake

Akk: is this up you alley?

Suggest: OS=all since in bug 56631 is was also seen with Windows2000.

Joe, is the follwoing covered by this bug?: copying from urlbar or any textfield (like in bugzilla) into the composer gives newline, text *in monospace*, newline. The formatting worries me most. It is plaintext what I am pasting, and I want no formatting, not <pre>. Pasting into another app, copying ther and pasting into Mozilla Composer works as expected. All on Linux.

moving to future, until we get the fix dates down

Filed bug 57041 about the problem mentioned.

moz 0.9

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

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

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

This also happens for text in <pre> blocks (in a browser window), such as in these bug reports. (Current Linux CVS trunk pull/build.) This also appears to happen for selections in non-<pre> text under some situations: if the selection starts at the start of a new paragraph or a new container, it appears to generate the newline on pasting. (Merely a new line, from a <br>, doesn't seem to do it.) Eg: on this web page, selecting 'Bugzilla Bug' and pasting will generate a newline, but selecting 'Bug List:' will not. Selecting 'Bug 55661 depends on' will, and so on.

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

Added self to cc.

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

I nominated 56135 for nsbeta1, and this is the same bug (not sure which Joe wants to be the real bug and which one the dup), so I'll nominate this one as well.

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

dup *** This bug has been marked as a duplicate of 56135 ***

Is this really a dup? Bug 56135 is about MailNews, this is about the Browser. And bug 56135 is about copying from the Subject field, this bug is about copying from/to anywhere in the browser.

it's the same bug, really.

vrfy dup

reopening. related issues in bug 56135 are fixed, but copying from pre's still exhibits this behavior, and will require a separate fix.

It's a bit complicated, because if I select across lines, I want to get the line breaks (e.g. if I select one stanza of a poem), but if I select just a word or two, I don't want line breaks. In other words, I do want line breaks that are inside the block I've selected; I just don't want an extra newline at the end of what I've selected (unless I've selected the entire contents of the pre block). Maybe that's not really that complicated after all.

What Akkana is asking for would just work if copies from inside pre's always copied as plaintext. If you pasted that into html, it would be a text insertion, and returns would automatically be converted into breaks. Getting a plaintext paste to exhibit the desired behavior is free. Making the determination that we want a plaintext copy is the hard part. All the other code that examines the selection during copy happens _after_ we have decided whether to do a text or html copy. I'll have to bend things around a bit to get this to work.

jfrancis, I can see your coding problems, but logically, it's easy: If the selection is only inside a <pre> (or exactly all of the <pre>), use plaintext flavor. If the user selects something outside the <pre>, use HTML flavor.

shouldn't soft returns be pasted as soft return (thus adjusting the linewraps to the new window width) and hard returns be pasted as hard returns? This would be the desired solution. I've also noticed that when pasting into a message, the text is pasted as "preformatted" text and not as "body" text, as one would expect. Paste should simply paste as plain text (body) unless the message one is pasting into AND the copied text are BOTH formatted.

> shouldn't soft returns be pasted as soft return (thus adjusting the > linewraps to the new window width) and hard returns be pasted as hard > returns? This would be the desired solution. There's nothing like soft returns in normal plaintext. > I've also noticed that when pasting into a message, the text is pasted as > "preformatted" text and not as "body" text, as one would expect. Yeah, that's what this bug is about. That "preformatted" (i.e. <pre>) is what causes the newline at the end.

would it be possible to put soft returns into plain text? Is mozilla or netscape capable of suggesting / implementing such a standard? (if not, who?) If either answer is yes, it should definetely be pursued as top priority and i will post a bug for it. This is still the *major* drawback of all e-mail formatting issues.

Please let's keep the focus on the bug. Such a discussion would be more appropriate in one of the newsgroups.

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

FYI, I'm still seeing this bug on 2001032614.

I'd like to add that this not only the case with <PRE>. Cut & paste from <H1>, <H2>, <H3>... also adds newline. Seen on Netscape 6.01A on Solaris 8/SPARC. Looks like this is the same bug?

sigh. this is not happening anytime soon.

need to investigate further before we work on the resolution

10 dups. Making mostfreq.

One alternative that would solve this and a host of other problems would be to *not* copy <pre> unless all of it is selected. Ie, make <pre> copy rules identical to the rules for other block elements. This would have the bad effect that you would lose the pre-formatting when copying parts of pres.

Again note that this is not only a <pre> issue. The same happens with <h1>, <h2>, <h3>, ...

Dimitir is correct. The H1, ..., H6 elements are the other blocks that behave like pre when we copy. Ie, we force them to be emitted even if you are only copying something inside them. Other blocks we don't copy unless you either: are copying everything inside them, or copy across at least on of the boundaries (start or end) of the block In contrast, there are lots of non-block elements that we will copy even if you only have some interior content selected. Basically all the tags that are used for stylistic purposes (b, i, u, tt, s, strike, em, strong, ....).

Joe, I don't think, it is a good idea to ignore <pre> (and thus plaintext formatting) when only parts are copied.

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

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

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

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

Dup bug 90340 is about View Source. Is the actual syntax of view source (we do not see it - bug 74862) a big <pre> block? If not, bug 90340 is not a dup of this one :-(

View-source uses a big <pre> block, yes.

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

Syd gave me permission to add nsbeta1 keyword to all bugs marked "[QAHP]" in the status whiteboard. These are Editor usability bugs and are important to fix for MachV. We will have another triage meeting at some later date and re-evaluate whether this bug is a MUSTFIX for MachV.

097

*** This bug has been marked as a duplicate of 98572 ***

verified.