122.67 KB, image/jpeg
147.87 KB, image/jpeg
154.52 KB, image/jpeg
(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.
Created attachment 5903 [details] Previewing post in Netscape 4.06 (Compare with preview of mozilla and then result)
Moving [DOGFOOD] in Summary to 'dogfood' in Keywords.
Putting on PDT- for beta1. Good luck with your marraige, but we cannot hold up beta1 for this. Sorry.
Buster, I start with you. Apparently when the submitter asks the GfxTextControl for text it isn't doing the correct thing with returns.
I meant dogfood for final release, not dogfood for beta 1.
assigned to akkana.
Yes, I have similar bugs on my M15 list (wish I could get authorization to look at them for beta).
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 ***
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.
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.
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...
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 ***