[PATCH] ActionView::Helpers::FormTagHelper.text_area_tag does not escape values

patch for the testcases to add a test for this bug

Fixes this, and adds an :escape => false option in case you do want unescaped contents.

To preserve backwards compatibility, among other reasons, this needs to be flipped. We add the :escape => true if we want to have something escaped. Otherwise, we'd break all the apps that use text_area_tag for editing content with intentional HTML. (Removed unverified keyword when complete).

I don't think we would break anything (unless someone has written code to work around the current broken text_area_tag implementation). If there's a '&' in your text area content that is intended to be edited as a '&', but is not intended to be parsed by your browser as part of your HTML document, then it should be escaped as '&'.

It's exactly the same as the way that the 'value' attribute of a text field input gets automatically escaped when it goes through tag().

In other words, the current text_area_tag():

1. generates bad HTML by default;
2. is inconsistent with text_area() (which does escape the content);
3. is inconsistent with all the other _tag() helpers (which do escape their values).

In the face of the above, I really think the default behaviour ought to be changed.

If anyone wants a demonstration of this, just set up a controller with:

@content = params[:content]

and a view with:

<%= form_tag %>
  <p><%= text_area_tag('content', @content) %></p>
  <p><%= submit_tag %></p>
<%= end_form_tag %>

Now, if you type in "<b>Hello & Goodbye!</b>" and hit submit a few times, you'll see that your angled brackets survive. But this is just an accident: it only works because the browser is being lenient with the shoddy HTML that text_area_tag is producing.

Now type in "&lt;b&gt;Hello &amp; Goodbye!&lt;/b&gt" (imagine you're writing a blog post and you want to demonstrate some HTML or something). Hit submit, and you'll see that a roundtrip to the server completely obliterates your carefully-typed entities. It spits them back literally into the HTML for the textarea tag, and your browser treats them as it should -- entities representing literal <, > and & characters in the content.

To fix this, all you need is a to change @content to h(@content). You'll see that the first test case still works perfectly as before, but now the second case works too.