Closed Bug 241263 Opened 20 years ago Closed 16 years ago

Sending (or encoding?) LF in form textareas

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: korte, Unassigned)

References

(Depends on 1 open bug,
URL
)

Details

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.
Is that GET or POST data?
--- 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.
Odd...  Our form submission code very explicitly converts linebreaks into CRLF
linebreaks (as required by both multipart and url encodings) in what it posts.....
I just experienced the very same problem with FireFox,&#10;&#10;Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040206&#10;Firefox/0.8&#10;
The last Bugzilla entry was made with FireFox, right after I encountered&#10;the problem inside of our own application, LON-CAPA.&#10;&#10;FireFox was a fresh installation from yesterday evening. I made no changes to&#10;the preferences except allow pop-up windows from our own server.&#10;&#10;I had not browsed any other sites except the FireFox welcome page and our own&#10;application.&#10;&#10;I never encountered this problem with previous versions of Mozilla or with&#10;FireBird and Camino.&#10;
Product: Browser → Seamonkey
The same thing happens to my colleagues who are Mac-users, even when using this very Bugzilla 
application itself.

Possibly related is Bug #169964
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?
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
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 &#10; in textareas, regardless of the web site.

Is there any place in the browser where dealing with CR, LF, CRLF, etc, gets
toggled?
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....
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 &#10;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.
Depends on: 331572
Gerd, have you seen this again in the last three years? Any new information to add? Or should this be resolved incomplete or WFM?
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."
OK, resolving WFM
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.