Skip to main content

Bug Tracker

Side navigation

#9007 closed bug (wontfix)

Opened April 28, 2011 04:50PM UTC

Closed September 22, 2011 04:12AM UTC

Last modified March 14, 2012 05:54AM UTC

Textarea value (via ".val()") differs from actual posted value (carriage returns are stripped)

Reported by: Pointy Owned by:
Priority: low Milestone: 1.next
Component: attributes Version: 1.5.2
Keywords: Cc: dmethvin, john, jaubourg
Blocked by: Blocking:
Description

See Ticket #6876 for some background.

When asked for the value of a textarea element, the ".val()" code strips all carriage return characters from the browser-reported value. However, when the value is submitted to the server, carriage returns are preserved (or added, by browsers that ''don't'' include them in the raw value), and (since #6876) jQuery makes sure they're there in the serialized version for XHR purposes.

The problem with this discrepancy between the field as reported by ".val()" and the actual submitted content is that when providing a sort of "maxlength" facility to report on available characters in a textarea, that code must account for the difference in cases where the carriage returns are preserved at the server (in my experience, a very likely thing). In other words, the "character countdown" must take into account the fact that when the textarea value (as reported by jQuery) contains newlines, then its ''actual'' length where it matters -- at the database, or in server-side validation code -- is greater by the number of newlines.

Now obviously this math is easy to do, and there may be all sorts of virtue in stripping those carriage returns. The behavior is not documented clearly, as far as I can tell; it's certainly absent from the description of ".val()". My observation is that in fact this discrepancy is unknown to many authors of exactly the sort of facility I described above.

http://jsfiddle.net/yNKmR/6/ is a crude jsFiddle that submits to a simple CGI script. The page provides a length counter, and the length (both raw and via ".val()") is sent to the server. It's quite clear to see that the posted textarea value contains more actual characters than accounted for by the jQuery ".val()" length. (Firefox and Webkit both behave like jQuery, so the raw length is also wrong.)

Attachments (0)
Change History (7)

Changed April 28, 2011 04:58PM UTC by SlexAxton comment:1

component: unfiledattributes
keywords: → val, textarea
milestone: 1.next1.7
priority: undecidedlow
status: newopen

Changed May 17, 2011 02:09PM UTC by dmethvin comment:2

This problem was precipitated by #6876 that converts a lone \\n to \\r\\n for consistency with standards. Opera and IE have \\r in the textarea value on Windows but most others don't. I think we want consistent cross-browser behavior here.

It seems like the only way to fix the problem of length mismatch is to have .val() consistently return \\r\\n but I shudder to think of what that would do to existing code.

Changed May 17, 2011 02:34PM UTC by timmywil comment:3

So right now, textarea.val() is consistent across browsers, but not consistent with what is sent with ajax. It makes sense to me that carriage returns are required for ajax, but new lines are used when val is retrieved. I'd say this could be needsdocs and we could start with a plugin that does a valHook for textarea.

Changed July 11, 2011 08:55PM UTC by addyosmani comment:4

cc: → dmethvin, john, jaubourg

I'd like to +1 timmywil's suggestion that this be moved to a needsdocs and start life as a plugin. Thoughts?

Changed August 30, 2011 08:32AM UTC by tomgrohl comment:5

I like timmywil's idea.

I've done a jsFiddle here with a valHook. Not sure if its much use or if I'm understanding the above correctly:

http://jsfiddle.net/tomgrohl/ekTwt/

If anything needs doing with this I'd love to help.

Changed September 22, 2011 04:12AM UTC by dmethvin comment:6

keywords: val, textareaneedsdocs
milestone: 1.71.next
resolution: → wontfix
status: openclosed

I agree, let's move this to a needsdocs. People who need to count exact characters can replace \\n with \\r\\n either through a hook like tomgrohl showed or by explicit code.

It would be great to fix this somehow in jQuery but we're stuck between the W3C standard for transmitting content with \\r\\n and the near-universal convention of a single \\n separating lines in a textarea.

Changed October 30, 2011 02:37AM UTC by addyosmani comment:7

keywords: needsdocs

Docs updated.