Support for e4x broken in GM 0.9.14?

[esquifit]

Hi,

I have quite a few scripts that make use of the following construction:

GM_addStyle(<><![CDATA[
(here comes normal css code)
]]></>);

This seems to be broken after the lastest GM upgrade, maybe even
before, but it was working for sure one month ago or so.

Currently I see that the script does not executes and the error console shows:

Error: can't wrap XML objects
Source file: <script file path>
Line: 409

Any idea what this could be? Since my Firefox is highly customized I
want to to be sure that others have also the problem before filing a
bug.

Running latest GM on Firefox 8 + Win7.

[DLo]

I've noticed this too -- a few GM scripts of mine have broken after
upgrading to FF10/Ubuntu and GreaseMonkey 0.9.15.

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.

[Anthony Lieuallen]

On Sun, Jan 22, 2012 at 2:15 PM, esquifit <esqu...@googlemail.com> wrote:

Any idea what this could be?

Generally no.  The more testing you do to narrow down which variable (Firefox, GM, etc) introduced the error, the less work someone else has to do to help figure it out.

[esquifit]

On Tue, Feb 7, 2012 at 8:53 PM, DLo <dlo...@gmail.com> wrote:
> I've noticed this too -- a few GM scripts of mine have broken after
> upgrading to FF10/Ubuntu and GreaseMonkey 0.9.15.
>
> 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();

The 'problem' is not GM but Firefox itself. It now requires an
explicit conversion of the e4x expression into a string. Note that
the correct way to do this is by using .toXMLString() and not
.toString(). This should fix the problem. It did for me.

> 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.

I've always used valid XML in e4x, even with Firefox 3.6 and GM 0.8x.
Anything else would throw an error.

On a related note I've found that some other things have change in the
Javascript interpreter that lead to many script ceasing to work.

1) the above mentioned explicit use of .toXMLString() after an e4x expression
2) implicit .exec does not work any more with regexps: before
/foo.*/(string) would do the same as /foo.*/.exec(string). Now only
the second one is allowed. The solution is to explicitly use .exec
(the short form was anyway non-standard).
3) array-like objects like HTMLCollections or NodeLists (as those
returned by getElementsByClassName, or querySelectorAll) are now
correctly handled by for each statements. Previously "for each (i in
collection)" would return only the elements of the array-like part of
the collection. Now it (correctly according to the ECMA specification)
returns other properties like 'length' or 'item' causing some script
to break. The solution is to re-formulate the whole expression so
that no "for...each" or "for each...in" is used, or the 'illegal'
elements are properly discarded. This varies from case to case.

I'd expect more quirks likes this, most of the related to the
Javascript implementation becoming more strict and closer to the
specs.