Closed Bug 596752 Opened 14 years ago Closed 14 years ago

bugzilla comments being submitted with stripped out linebreaks

Categories

(Core :: DOM: Editor, defect)

defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 596455
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: Gavin, Assigned: ehsan.akhgari)

References

Details

(Keywords: dogfood, regression)

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.
blocking2.0: --- → ?
Severity: normal → major
Keywords: dogfood
A pair of line breaks was stripped from bug 596805 comment 0, between two blocks I had pasted from other applications.
Assignee: nobody → ehsan
blocking2.0: ? → beta7+
(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
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.
Depends on: 596506
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.
Depends on: 596455
No longer depends on: 596506
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...
No longer blocks: 240933
Let's do that
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.