This is a child of bug #3474. 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, for example like this: <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=""> According to HTML4, the carriage returns in the "value" attribute for the "comment" field should be collapsed to spaces. Thus correctly working browsers (including Mozilla) collapse the spaces, and the comment field should lose the hard returns. Possible solutions to this problem include: 1. %-encode the comment field's value attribute, as is done for URIs. 2. Escape line breaks. 3. Use a TEXTAREA instead of an INPUT element, with the attribute: style="display:none" Solution 1 is by far the best method. You should be able to lever some code from other parts of the codebase to implement it. Solution 2 may be easier if there is no code to use. Solution 3 is not backwards compatible.

Solution 2 seems pretty wonderful to me -- I don't know what you dislike about it -- and I have implemented it. The problem with solution 1 is that the browser does not URI-decode value fields for me. So I would have to know for any given field whether it was URI-encoded or not, and do the decoding myself. This is bug-prone. Fixed.

The current system causes blank lines to appear in comment fields (eg, on this page, when viewed in IE4). This is because some blank lines are escaped as &#013;&#010; instead of just &#013;. This appears to occur on all line breaks but the first one. Note, though, that the CRLF issue is a complex one. For example, the SGML and HTML specs disagree. To be on the safest side, you should ensure that all #13#10 and #10#13 pairs and every lone #10 are escaped as simply &#13. (The SGML spec says that all #10 characters should be ignored.)

Apparently, bug 5183 has some samples of problems that I believe are caused by this.

Reassigning to dmose@mozilla.org, who now has front-line responsibility for all Bonsai and Bugzilla bugs.

Increasing priority as this is affecting every bug in bugzilla and is making it difficult to read bugs.

I thought I fixed this for once and for all this morning. Are you saying that you still get the double-spacing effect?

No, I don't anymore. Shouldn't it be marked fixed, then? (And is this the cause of the weird diff posts I just e-mailed you about?)

I didn't mark it fixed entirely because I thought you were saying it wasn't. And yes, this was causing weird diff stuff, until I fixed that. Marking FIXED now.

Both the spacing and the diff problems seem to be fixed. Marking verified.

I don't think this is fixed. See bug 2742. (And no, I don't mean the content. Just my submission using Mozilla on 1999-05-10.) Reopening bug.

The same thing happened above. I viewed source and you don't seem to be using the hidden fields anymore. Are you using cookies or something?

Actually, the above didn't work even without the login form. So is this a bugzilla problem or a Mozilla problem?

I seem to have to use hard returns to get the textarea to submit returns. I've run into that before but I thought it was fixed. Re-resolving bug. However, I'll use this bug to test bugzilla again on my next build.

Sorry. The Mozilla problem is bug 2442.

No bugzilla problems with the escaping AFAICT.

Moving to Bugzilla product

This apparently breaks the parameters page in Opera 6.0 on Linux. The newlines in the forms go away when the form page is created, and this b0rks all the email params when you save any parameter changes. I guess it's an Opera HTML problem but I am not sure.

I no longer own Bugzilla.

This is not the same bug. See bug 97980

see previous comment. re-marking fixed.

restoring previous verified status