Potentially related to bug 596455. See these comments: bug 578967 comment 124 bug 591981 comment 24 bug 595356 comment 17 bug 595356 comment 15 They all are missing newlines. I think this is likely a bug with trunk builds, but I have no more information than that.

A pair of line breaks was stripped from bug 596805 comment 0, between two blocks I had pasted from other applications.

(In reply to comment #1) > A pair of line breaks was stripped from bug 596805 comment 0, between two > blocks I had pasted from other applications. I'll investigate to see if pasting has some relevance here.

Happened to me twice: bug 582795 comment 38, and bug 582795 comment 39.(Linebreak.)Wonder if it happens here.Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20100916 Firefox/4.0b7pre

I can't reproduce at http://tedscomputer.homeip.net:9000/show_bug.cgi?id=5 (Linebreak.)

Justin, you can also try this instance: https://landfill.bugzilla.org/bugzilla-3.6-branch/

I can't reproduce at https://landfill.bugzilla.org/bmobranchmaint/show_bug.cgi?id=9095#c1 either, which is the same code as runs Mozilla's bugzilla.Not sure what to do now.

(In reply to comment #5) > Justin, you can also try this instance: > > https://landfill.bugzilla.org/bugzilla-3.6-branch/ Can't seem to reproduce there either. (paragraph)

This just happened to me; see https://bugzilla.mozilla.org/show_bug.cgi?id=597037#c1 Doing a test in this comment. A test

Doing a test with Firebug's net panel enabled. I wonder if I'll see it. I wonder what's causing it. Doing a test in this comment.

And that didn't reproduce it. :( And when I reposted the comment in the other bug it worked there.Are we ending up with an uninitialized variable somewhere that we use to decide whether to convert newlines to spaces or not.

What I noticed recently is that things like this can happen due to the end of the line suddenly not being the end of the line. ;-) When you type something in a textarea in recent builds and have a line break in there, if you press the "end" button, the cursor appears at the end of the line, but in fact you have an editing position *after* the line break (same with middle-mouseclick-pasting at the end of a line) and things insert at the beginning of the next line. If you press the back arrow when the cursor is in that position, the cursor marker doesn't move, but suddenly you're at the actual end of the line, right before the line break. Not sure if that's exactly the bug that leads to this losing of linebreaks, but I had it happening this way, and I suspect that might affect others the same way.

(In reply to comment #11) > When you type something in a textarea in recent builds and have a line break in > there, if you press the "end" button, the cursor appears at the end of the > line, but in fact you have an editing position *after* the line break [...] This is separate, bug 596506.

So we have a theory which says that this happens (at least) from the mid-air page, which would mean that this is happening as a result of bug 596455. Can people who've come across this problem comment on whether they submitted their comment through the mid-air page or not?

The missing lineberak in bug 596805 comment 0 didn't involve a midair, but it might have involved bug 596506.

Note that in the context of comment 13 "mid-air" includes anything that makes you submit again (mid-air, ambiguous cc, "you're filing a bug you already filed" page, whatever).

I'm pretty sure I've lost linebreaks without going to any kind of intermediate page. Newline.

I'm 99.9% sure that fixing bug 596506 will make this problem go away.Note that bug 596506 was caused by a change that happened on the same day as bug 240933 landed.

So can someone verify that this is fixed now that 596506 has landed?

Er... I pasted the wrong bug number in comment 17. I meant bug 596455. That's still waiting on review and hasn't landed.

See bug 571507 comment 4 for a testcase.

(In reply to comment #20) > See bug 571507 comment 4 for a testcase. Yes, this happens because newlines are stripped from <input type=hidden> fields (see bug 596455 for details). In fact, I'm kind of inclinded to mark this as a dupe of that bug, and reopen if people see this behavior after bug 596455 has landed...

Let's do that