Update: Over on the Greasemonkey mailing list, Joe la Poutre notices an even easier workaround. All you have to do is use the older form of the XPCNativeWrapper constructor to access a specific property. I'm not even sure why this works, but it does:var parser = new XPCNativeWrapper(window, "DOMParser").DOMParser();
alert(parser.parseFromString("", "text/xml"));
Leaving the below, just for posterity...
One bittersweet part about releasing Greasemonkey 0.6.4 was that I needed to remove support for the
XML Extras module which contains such goodies as
XMLHttpRequest,
DOMParser, and
XMLSerializer.
I knew that many people were using XMLHttpRequest, particularly since GM_xmlhttpRequest, it's cross-domain replacement evaporated temporarily in 0.3.5, and that this would be a pain point. However, when weighing those people having to change their scripts to use GM_xmlhttpRequest and the alternative of having a confusingly inconsistent security model, I chose the former. I also fixed the major scripts I knew of, such as
GMail Conversation Preview, which used XMLHttpRequest.
What I didn't expect at all was that people would miss DOMParser and XMLSerializer. I had no idea any scripts even used these. It's really neat to
find people using pieces of your tool which you didn't expect them to, in ways you didn't expect them to. This makes me incredibly happy. Go user scripters! :-)
Anyway, to make a long story short, I've received many questions asking how to work around the lack of these two classes. The good news is that not only is there a workaround, there are three of them!
1. Use unsafeWindow.DOMParser and unsafeWindow.XMLSerializerThe downside here is that, as the name says, unsafeWindow is a reference to the content actual window - the same one that the content's JavaScript uses. Because of that, calling into it can make your script vulnerable to interference by the content script. This can be OK if you trust the site you are scripting somewhat. Take a look at the
unsafeWindow details to decide whether you think this is appropriate for your script.
2. Use E4XIn a very zen turn of events it turns out that although Firefox 1.5 denies user scripters the XPCOM-based XML parsing and serializing they were accustomed to, it provides them with a brand-new - arguably superior - interface.
E4X is a brand new native JavaScript XML API that ships with Firefox 1.5 and is available to Greasemonkey scripts. There's not a ton of documentation yet, but from my experience with it so far, it's vastly more elegant and pleasant to work with than the DOM interfaces.
You can get more information about E4X, including the ECMA specification and a handy expression tester, at these URLs:
http://developer.mozilla.org/en/docs/E4X
http://www.ecma-international.org/publications/standards/Ecma-357.htm
http://www.linkwerk.com/pub/javascript/e4x/e4x-tester/
One caveat to keep in mind is that, in accordance with the E4X spec (don't ask me, it's insane), the input XML must
not have an XML declaration. So you usually need to use a regex to strip it before parsing. For example:
var xml = new XML(xmlStringWithDecl.replace(/<\?xml.*?\?>/g, ""));
3. Use an IFRAME and let Mozilla do the dirty workMany have pointed out that Mozilla already ships with an excellent, and very robust XML parser. It also ships with an HTML parser. Why not just leverage those? You can, it just takes a bit of hacking. I put an example of how to use an IFRAME to parse an HTML document into a DOM on my website.
Greasemonkey HTML ParserOf course, just by changing the content type from
text/html to
text/xml, you could use the same technique to parse XHTML or even raw XML.
So I hope this shows that although the way to do certain things has changed, no capabilities have been removed from Greasemonkey. In fact new ones have been added, and the addition of completely isolating user scripts from content improved the reliability and security of Greasemonkey quite a lot.
Sorry for the disturbance, you may now resume your madcap exploration and use of Greasemonkey for all manner of things I never expected.
