Single linefeed (\n) handled inconsistently in FormData()
Reported by
j...@visualjerk.de,
Dec 20
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Steps to reproduce the problem: 1. Create a form with a textarea 2. Set the textarea value to '\n' 3. Create FormData from the form 4. Get the value of the textarea through FormData.get For details see this codepen: https://codepen.io/CharlyTheDog/pen/GPrzbr?editors=1112 What is the expected behavior? The result of FormData.get should be '\n' What went wrong? The result of FormData.get is '\r\n' Did this work before? N/A Chrome version: 71.0.3578.98 Channel: stable OS Version: OS X 10.13.5 Flash Version: The provided example works as expected in latest Firefox and Safari.
,
Dec 21
See https://html.spec.whatwg.org/multipage/form-elements.html#textarea-line-break-normalisation-transformation >>> For historical reasons, the element's value is normalized in three different ways for three different purposes. The raw value is the value as it was originally set. It is not normalized. The API value is the value used in the value IDL attribute, textLength IDL attribute, and by the maxlength and minlength content attributes. It is normalized so that line breaks use U+000A LINE FEED (LF) characters. Finally, there is the value, as used in form submission and other processing models in this specification. It is normalized so that line breaks use U+000D CARRIAGE RETURN U+000A LINE FEED (CRLF) character pairs, and in addition, if necessary given the element's wrap attribute, additional line breaks are inserted to wrap the text at the given width.
,
Dec 21
Tried testing the issue on chrome version #60.0.3112.113 and reported chrome version #71.0.3578.98 using Mac OS 10.13.6 by following steps as per comment#0. Observed that in the console it displays false, false and true in chrome version #71.0.3578.98, in #60.03112.113 it displays true, false and false whereas in firefox it id displaying true, true and true. Attached screenshots for reference. @reporter: Could you please review attached screenshots and let us know if this is the issue you are pointing to. Thanks.!
,
Dec 22
Yes, that is exactly the issue we experienced. However as you stated above it seems to be expected behavior, that a single LF inside a textarea is normalized to CRLF. It looks like Firefox is handling this incorrectly. When the FormData is send by an XHR however Firefox normalizes single LF to CRLF regardless of where the data originally came from (textarea element or FormData.append()). Chrome doesn't do any normalization of line breaks XHR level, right?
,
Dec 22
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 26
Able to reproduce the issue on the reported chrome version #71.0.3578.98 and latest chrome #73.0.3652.0 using Ubuntu 17.10, Windows 10 and Mac OS 10.13.6 by following steps as per comment #0. The behaviour is observed from old M-60 builds(#60.0.3112.11). This is a non-regression issue hence, marking it as untriaged and requesting someone from the dev team to look into the issue. Thanks.!
,
Dec 26
Safari matches Firefox, which is a bit unexpected on Mac. Over to Editing to confirm this is WontFix.
,
Dec 27
Chrome conforms to the specification. 'new FormData(form)' invokes [1], and it appends textareas's value, of which line endings are converted to CRLF, not API value. FormData.append() doesn't do such conversion. [1] https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#constructing-form-data-set |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by gov...@chromium.org
, Dec 20