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, Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
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.
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 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 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.
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
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.