29677 - Posts to "Swoon" improperly formatted.

Status: VERIFIED DUPLICATE of bug 22707

(Core :: DOM: Core & HTML, defect, P3)

Description

[Jason Eager]

(This is Dogfood because if we don't get this fixed, then my fiancee
will not regularly use the beta, and it is also a big annoyance to
me (because Netscape 4.06 has a memory leak when typing into a large
box which makes it crash before I can post a long post)

Problem: When posting to Swoon (a web based forum) using any recent
mozilla builds, the post appears to be properly formatted when
previewing it, but the final post is incorrectly formatted. It lacks
any carriage returns, the entire message appears on one (LONG) line.

Obviously, we are doing something different from the Netscape 4.X series,
and that may break compatibility with other web based forums
besides this one.

The above URL leads to posts that I made (on a forum soon to be
archived, so it wouldn't disturb anyone) with two mozilla nightly
builds, and Netscape 4.06. The formatting in the Netscape 4.06 post
should be considered the expected result, the formatting in the mozilla
posts should be considered the buggy result.

I've taken screen shots of the different parts of the posting process,
and I'll add them to this bug now.

Comment 1

[Jason Eager]

Attachment: Previewing post in Netscape 4.06 (Compare with preview of mozilla and then result)

Comment 2

[Jason Eager]

Attachment: After finishing typing post in Mozilla (but before previewing)

Comment 3

[Jason Eager]

Attachment: Previewing post in mozilla (Compare with final result)

Comment 4

[leger]

Moving [DOGFOOD] in Summary to 'dogfood' in Keywords.

Comment 5

[leger]

Putting on PDT- for beta1.  Good luck with your marraige, but we cannot hold up 
beta1 for this. Sorry.

Comment 6

[rods (gone)]

Buster, I start with you. Apparently when the submitter asks the GfxTextControl 
for text it isn't doing the correct thing with returns.

Comment 7

[Jason Eager]

I meant dogfood for final release, not dogfood for beta 1.

Comment 8

[buster]

assigned to akkana.  

Comment 9

[Akkana Peck]

Yes, I have similar bugs on my M15 list (wish I could get authorization to look
at them for beta).

Comment 10

[Akkana Peck]

I don't understand this bug (the parts that say they rely on automatic word wrap
are in fact wrapped ... it looks like maybe the second attachment is the one
that's supposed to show the error, except that it wasn't scrolled down to where
the actual error occurred?) and would need a better test case ... but I'm going
to take a guess that maybe this is related to bug 28598, which concerns sites
which add \r (which is an illegal character in the dom -- the dom uses \n for
line breaks) which then does not get submitted properly.  I'll go ahead and mark
this a dup, but if anyone thinks I've misunderstood, please reopen and explain
what the bug really is and how I can reproduce it.

I have a fix for 28598 bug which I'm going to check in tomorrow.

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

Comment 11

[Jason Eager]

Bug still exists.

Follow the URL (at top), and you'll find a thread that I've started on swoon
that shows this bug, along with my latest post that demonstrates that the
bug still exists.

The bug is:

1) I type a post, either with automatic line feeds, or manual line feeds.
2) I go to preview a post, and the line feeds are still there.
3) I go to read the post that I finalized, and there are NO line feeds. The
message appears in one long stream across the web page.

This bug appears in many other places then swoon like:

1) Some of my posts to bugzilla are double spaced.
2) Some of my posts to Slashdot also appear double spaced.
3) Some other places (I don't have a list right now but I will soon) have
trouble handling my input if it involves a line break.

Comment 12

[Akkana Peck]

I think we're really going to need some help from swoon for this one, or some
help from someone who can provide a test case where we can see what's happening
to the data after we post it.

When we get the output from nsGfxTextControlFrame, it does indeed have newlines
in it.  Someone later apparently strips off those newlines (perhaps in form
posting, but it also could be happening in swoon's own software).  I'm sending
it over to pollmann and nisheeth to look at whether something might be going
wrong in form posting of wrap=hard data after it leaves the text widget.

I wrote a little test case to try to debug this, but everything works fine in
the test case.  I'll attach it anyway, in case someone wants to go from there.

Comment 13

[Eric Pollmann]

The problem is this (in the preview page):

<INPUT TYPE=HIDDEN VALUE="foo
foo">

The carriage return in the value of the hidden input is stripped out.  I believe 
this bug is already reported, I'll look for the dup...

Comment 14

[Eric Pollmann]

This is an exact duplicate of bug 22707.  It looks like it is probably invalid 
too (except that the CRLF should be converted into a space instead of dropped 
altogether).  This is one situation in which the spec is in direct conflict with 
industry practice, so it might make sense to leave the CRLF in the value for 
compatability mode, and strip it out for strict mode.

The bug is currently scheduled for M18, but if it really is dogfood, should be 
bumped up.

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

Comment 15

[Matt Perry]

Verified duplicate.