Bug in Chrome, or Stupidity in User? Sanitising inputs on forms?

Question

I've written a more detailed post about this on my blog at: http://idisposable.co.uk/2010/07/chrome-are-you-sanitising-my-inputs-without-my-permission/

but basically, I have a string which is:

||abcdefg
hijklmn
opqrstu
vwxyz
||

the pipes I've added to give an indiciation of where the string starts and ends, in particular note the final carriage return on the last line.

I need to put this into a hidden form variable to post off to a supplier.

In basically, any browser except chrome, I get the following:

<input type="hidden" id="pareqMsg" value="abcdefg
hijklmn
opqrstu
vwxyz
" />

but in chrome, it seems to apply a .Trim() or something else that gives me:

<input type="hidden" id="pareqMsg" value="abcdefg
hijklmn
opqrstu
vwxyz" />

Notice it's cut off the last carriage return. These carriage returns (when Encoded) come up as %0A if that helps.

Basically, in any browser except chrome, the whole thing just works and I get the desired response from the third party. In Chrome, I get an 'invalid pareq' message (which suggests to me that those last carriage returns are important to the supplier).

Chrome version is 5.0.375.99

Am I going mad, or is this a bug?

Cheers, Terry

Answer 1

Normally in an input box you cannot enter (by keyboard) a newline.. so perhaps chrome enforces this even for embedded, through the attributes, values ..

try using a textarea (with display:none)..

Answer 2

Confirmed it here. It trims trailing CRLFs, they don't get parsed into the browser's DOM (I assume for all HTML attributes).

If you append CRLF with script, e.g.

var pareqMsg = document.forms[0]['pareqMsg']
if (/\r\n$/.test(pareqMsg.value) == false)
   pareqMsg.value += '\r\n';

...they do get maintained and POSTed back to the server. Although the hidden <textarea> idea suggested by Gaby might be easier!

Answer 3

You can't rely on form submission to preserve the exact character data you include in the value of a hidden field. I've had issues in the past with Firefox converting CRLF (\r\n) sequences into bare LFs, and your experience shows that Chrome's behaviour is similarly confusing.

And it turns out, it's not really a bug.

Remember that what you're supplying here is an HTML attribute value - strictly, the HTML 4 DTD defines the value attribute of the <input> element as of type CDATA. The HTML spec has this to say about CDATA attribute values:

User agents should interpret attribute values as follows:

• Replace character entities with characters,
• Ignore line feeds,
• Replace each carriage return or tab with a single space.

User agents may ignore leading and trailing white space in CDATA attribute values (e.g., " myval " may be interpreted as "myval"). Authors should not declare attribute values with leading or trailing white space.

So whitespace within the attribute value is subject to a number of user agent transformations - conforming browsers should apparently be discarding all your linefeeds, not only the trailing one - so Chrome's behaviour is indeed buggy, but in the opposite direction to the one you want.

However, note that the browser is also expected to replace character entities with characters - which suggests you ought to be able to encode your CRs and LFs as 
 and 
, and even spaces as  , eliminating any actual whitespace characters from your value field altogether.

However, browser compliance with these SGML parsing rules is, as you've found, patchy, so your mileage may certainly vary.