When I type enter in a textarea, it isn't being submitted properly. For example, there is a blank line between each sentence in this submission. This probably won't work, but if it does, it didn't at the URL above.

Did you check in a fix this Kevin? It works correctly for me in the most recent builds (could not reproduce at http://blueviper/forms/test.html => http://blueviper/forms/testDisplay.cgi?element=TextArea) I just noticed this is related to bug 1829. (Windows text widgets need \r\n to display a linefeed, not just \n) Here's an interesting and annoying fact: Windows submits %0d%0a to represent a linefeed while unix submits only a %0a. Communicator seems to have standardized on %0d%0a (I just tried Linux 4.51 and got this anyhow) Should we do the same with SeaMonkey?

Test from Windows Seamonkey Blank line \/ Test from Windows Seamonkey Blank line /\

Test Test

The

Opps. What I meant to say was: The entry reading "Test from Windows Seamonkey Blank line \/ Test from Windows Seamonkey Blank line /\" was submitted before I logged in to bugzilla. There was a double line feed between the two "Test from Windows Seamonkey"s The entry reading "Test Test" was submitted (also by Windows Seamonkey) after logging into bugzilla. There was also a double line feed between the two "Test"s. So the first submission appears to be a bugzilla bug.

This is being submitted with NN 4.5 before logging into bugzilla. There are two blank lines here: And this is a line. And this is a line. (I expect this to work.)

The problem here has to do with the parsing of attributes. I'm 80% sure Mozilla is correct, and Bugzilla is exploiting a bug in all the other browsers. What's happening is that bugzilla's login form after submitting info on a bug when you're not logged in contains all the stuff that you've submitted within the form, as hidden values. So, for the above, it had: <input type=hidden name=assigned_to value="kmcclusk@netscape.com"> <input type=hidden name=component value="Form Submission"> <input type=hidden name=comment value="This is being submitted with NN 4.5 before logging into bugzilla. There are two blank lines here: And this is a line. And this is a line. (I expect this to work.)"> <input type=hidden name=form_name value="process_bug"> <input type=hidden name=resolution value="FIXED"> <input type=hidden name=dup_id value=""> I believe Mozilla's behavior is correct, but not sure.

Mozilla is correct. This was covered by bug #2756. The line breaks in the value attribute above should be collapsed to spaces. Here is what HTML4 spec says about the contents of CDATA attributes such as value, alt, title, href, longdesc...: CDATA is a sequence of characters from the document character set and may include character entities. User agents should interpret attribute values as follows: o Replace character entities with characters, o Ignore line feeds, o Replace each carriage return or tab with a single space. User agents may ignore leading and trailing white space in CDATA attribute values (e.g., " myval " may be interpreted as "myval"). from http://www.w3.org/TR/REC-html40/types.html#h-6.2 This bug has spawned bug #4928.

dbaron, could you please verify this? thanks!

Verifying invalid. It is a bug in bugzilla. It may, however, need to be reconsidered for compatibility mode, but would be difficult to implement without breaking lots of other stuff, I would think.