FLUID-3224: If <textarea> autobound to non-existant model field, Renderer renders unclosed element

Description

If a <textarea> element in the template is autobound to a field that happens to be absent from the data model, the Renderer renders the textarea, but doesn't close it - any subsequent markup is displayed by the browser as though it is the content of the textarea.

I'm not sure what the Renderer should be doing in this case, but the observed behaviour is quite disruptive: the rest of the page disappears!

Comments

• Antranig Basman commented 2009-11-29T00:31:40.000-0500

  This was a surprisingly subtle issue, and only bites when the <textarea> element in the template has no content. It is related to the failure of XHTML documents in general to be invalid in many browser contexts - the emitted markup in this case was correct as XHTML, containing the text <textarea/> - however, when passing through the innerHTML mechanism of the browser, this was immediately degraded to <textarea> causing corruption of the rest of the document.
  The renderer now makes use of the "closed tags list" which is already present in the fastXmlPull library in order to determine what kind of markup to emit for tags with no content in fluidRenderer.dumpTemplateBody(). This is a slightly undesirable cross-reference but there is in all cases so far a dependence on this library anyway. The opportunity was taken to clean up fastXmlPull's use of global namespace which is reduced now to the two symbols "XMLP" and "SAXStrings". At some point we should review whether fastXmlPull should not be just brought formally under standard Fluid namespacing and version management.

• Justin Obara commented 2009-11-30T09:26:48.000-0500

  Just wondering why there are a couple of lines commented out in the unit test.

• Antranig Basman commented 2010-02-09T19:53:38.000-0500

  I've added a comment in the test case explaining the reason for the alternative branch, during the work on FLUID-3493. For these two tests which have the potential to generate invalid markup, it is safer to test the raw text of the renderer output rather than the version after transfer through the DOM. I have factored out a "renderManually" utility function to make these kinds of tests easier to write, although this should be easier to achieve than it is with the current API.

• Justin Obara commented 2010-02-10T09:28:14.000-0500

  Unit test all seem to be passing... handing this issue off to anastasia to ensure that it works in the context she discovered the issue.

• Anastasia Cheetham commented 2010-04-13T12:01:53.000-0400

  I can no longer reproduce this in the context in which I originally found it.