241263 - Sending (or encoding?) LF in form textareas

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Gerd Kortemeyer]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113

Mozilla appears to send linefeeds into form textareas. I blamed out application
first for not handling these correctly, but when I filed a bug in our Bugzilla
(BTW, thank you for this wonderful application!), I noticed that at least our
version of Bugzilla also choked on it's own Mozilla.

Reproducible: Sometimes
Steps to Reproduce:
Fill out a form with a textarea, submit, view the result.
Actual Results:  
The hard returns get turned into 
, for example:

"the linebreaks get totally
messed up."

Expected Results:  
the linebreaks get totally
messed up.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Is that GET or POST data?

Comment 2

[Gerd Kortemeyer]

--- In our application:
Method is POST.
Encoding: Default
Target: None (opens in same window)

<form name="lonhomework" method="POST" action="/~korte/essay.problem">
...snip ...
<textarea rows="4" cols="80" name="homework_edit_1_1">This is my test.

Test
</textarea>

--- In Bugzilla:
Method is POST.
Encoding: Default
Target: None (opens in same window)

<form name="changeform" method="post" action="process_bug.cgi">
... snip ...
<textarea wrap="hard" name="comment" rows="10" cols="80"
            accesskey="c">

... what's really confusing about this is that I was unable to detect a pattern
when LF gets submitted, and escaped, and when it does not. As you look at the
Bugzilla URL I gave, my entries have all been written with the same browser ...
some of them turned out fine, others were messed up.

I did not experience these problems with Mozilla 1.3 on the same laptop with
unchanged operating system, even though I worked extensively with both our
application and with Bugzilla.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Odd...  Our form submission code very explicitly converts linebreaks into CRLF
linebreaks (as required by both multipart and url encodings) in what it posts.....

Comment 4

[Gerd Kortemeyer]

I just experienced the very same problem with FireFox,

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040206
Firefox/0.8


Comment 5

[Gerd Kortemeyer]

The last Bugzilla entry was made with FireFox, right after I encountered
the problem inside of our own application, LON-CAPA.

FireFox was a fresh installation from yesterday evening. I made no changes to
the preferences except allow pop-up windows from our own server.

I had not browsed any other sites except the FireFox welcome page and our own
application.

I never encountered this problem with previous versions of Mozilla or with
FireBird and Camino.


Comment 6

[Gerd Kortemeyer]

The same thing happens to my colleagues who are Mac-users, even when using this very Bugzilla 
application itself.

Possibly related is Bug #169964

Comment 7

[Boris Zbarsky [:bzbarsky]]

Gerd, is there a website that shows the problem reliably with a current mac
trunk build?  If so, what is the URL of that site and the steps to reproduce?

Comment 8

[Gerd Kortemeyer]

This very Bugzilla site itself does it, see earlier entries in this bug report.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040910

Comment 9

[Gerd Kortemeyer]

The bigger question is actually how to get Mozilla into this state, which
neither I nor my colleagues have not figured out yet. Once it is in this state,
it always sends the 
 in textareas, regardless of the web site.

Is there any place in the browser where dealing with CR, LF, CRLF, etc, gets
toggled?

Comment 10

[Boris Zbarsky [:bzbarsky]]

Not as a preference, I don't think... Could you take a browser showing the
problem and one not showing it and compare the prefs.js files, though?  Could
you compare what character encoding they show for a page where incorrect data is
sent?

And again, is this a problem in a _trunk_ build?  The 1.7 branch is a bit old....

Comment 11

[Gerd Kortemeyer]

This is something that switches while browsing, not through the preferences.

It would work fine, but then while working get into a state where it would
generate 
s. Once it is in that state, it would do so across different
websites including this very Bugzilla.

Completely quitting the browser seems to reset it.

This happens to me and two colleagues with different versions of Mozillas, but
only on MacOS X - we do not have this problem on Windows or Linux.

I have now downloaded

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20050103

and will see if it happens again. Since I don't know what triggers the switch, I
am not sure how to make the problem happen on demand.

Comment 12

[Peter Weilbacher]

Gerd, have you seen this again in the last three years? Any new information to add? Or should this be resolved incomplete or WFM?

Comment 13

[Gerd Kortemeyer]

No, I have not seen this recently.

In the meantime, of course, both the OS on my machine and Firefox had frequent updates.

WFM is probably appropriate, it somehow "solved itself."

Comment 14

[Andrew Schultz]

OK, resolving WFM