Some preliminary investigation I've done suggests that this may be
related to strict XML parsing inside the cdata.  For example, I use
the
var myVar = <str><![CDATA[
....
]]></str>.toString();
approach to include HTML template strings in my GM scripts -- strings
of 'proto-HTML' that I embed inside my GM scripts to create new HTML
elements on my "fixed" pages after passing the string through an HTML
templating framework.  I've found that after my FF/GM update, my
scripts fail if my CDATA contain something like: "<input type='radio'
id='blah'>" but works fine if my CDATA contains "<input type='radio'
id='blah'/>" (ie include trailing end-tag slash).  That seems to imply
that GM or the e4x engine is being extremely picky about the contents
of the CDATA containing strictly-correct XML.

In reality, this is very frustrating.  The purists will say "oh, well
you should be writing valid XML!".  That's cute... but how many of you
actually write XML to the strictest of standards?  If FF can parse it,
let me use it.  More importantly, though, when using strings as HTML
templates, you don't always follow strict XML because it's intended to
be proto-XML that gets read by your templating framework and turned
into valid HTML.

Furthermore, this implies that the "var myVar = <str><!
[CDATA[ ... ]]></str>.toString();" approach, described here:
http://wiki.greasespot.net/Multi_Line_Strings as a solution to the
multi-line strings problem, requires it's contents to be well-formed
XML, which makes its use as a general multi-line string solution
limited and prone to frustration.

On Jan 22, 2:15 pm, esquifit <esqui...@googlemail.com> wrote: