Strange behaviour of DomParser in a module

General discussion, compatibility and contributed extensions.

Moderators: satrow, Lootyhoof, FranklinDM

thosrtanner
Fanatic
Fanatic
Posts: 189
Joined: 2014-05-10, 18:19
Location: UK

Strange behaviour of DomParser in a module

Unread post by thosrtanner » 2019-02-05, 22:25

I've been busy converting something into a module, which was previously included from a <script> command in an overlay extension. Part of that code uses DomParser. For which you have to use

Code: Select all

const DOMParser = Components.Constructor("@mozilla.org/xmlextras/domparser;1", "nsIDOMParser");
however, it promptly blue up on some XML that it had previously accepted. Fortunately you get some trace in the console saying where it had got upset. And what it didn't like was a tag that had the attribute

Code: Select all

xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"'
I don't really understand why it should error that. Firstly it was totally happy with that when I was using the non module DomParser(). Secondly, that's not invalid XML.

It's easy enough to get round - I just strip that tag out of the file before I process it. I'm not sure how it got in there, though I imagine once it was in, it will have stayed in because of the way the code deals with the XML. But it is a somewhat disconcerting difference in behaviour.

User avatar
JustOff
Localization Coordinator
Localization Coordinator
Posts: 1727
Joined: 2015-09-03, 19:47
Location: UA
Contact:

Re: Strange behaviour of DomParser in a module

Unread post by JustOff » 2019-02-05, 23:05

Can you provide an example of xml and code that reproduces this issue in the Scratchpad or a test add-on?
Here are the add-ons I made in a spare time. That was fun!

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 23234
Joined: 2011-08-28, 17:27
Location: 58°2'16"N 14°58'31"E
Contact:

Re: Strange behaviour of DomParser in a module

Unread post by Moonchild » 2019-02-06, 00:56

There's 2 things here that stand out:

First, you're using const on an interface constructor. With the change to a global JS scope, "let" and "const" in the root scope can be problematic since they will create global-static objects now. Trying to reference those later on can be a problem.

Second, I notice an errant single quote at the end of your namespace string -- that could throw off the strict XML parser.
Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

thosrtanner
Fanatic
Fanatic
Posts: 189
Joined: 2014-05-10, 18:19
Location: UK

Re: Strange behaviour of DomParser in a module

Unread post by thosrtanner » 2019-02-06, 19:53

firstly that const is in a module, so won't, as I understand it, affect the global namespace.

secondly the trailing ' is a typo, sorry. I cut and pasted too much from my workaround

thosrtanner
Fanatic
Fanatic
Posts: 189
Joined: 2014-05-10, 18:19
Location: UK

Re: Strange behaviour of DomParser in a module

Unread post by thosrtanner » 2019-02-06, 20:53

JustOff wrote:Can you provide an example of xml and code that reproduces this issue in the Scratchpad or a test add-on?
Initial attempts to get a minimum reproducible example have not been going too well. hopefully i can cut it down from 128k somehow

vannilla
Lunatic
Lunatic
Posts: 388
Joined: 2018-05-05, 13:29

Re: Strange behaviour of DomParser in a module

Unread post by vannilla » 2019-02-07, 00:03

thosrtanner wrote:firstly that const is in a module, so won't, as I understand it, affect the global namespace.
I believe what Moonchild is trying to say is unrelated to the namespace.

Anyway, have you tried building the DOMParser using different methods? https://developer.mozilla.org/en-US/doc ... IDOMParser

thosrtanner
Fanatic
Fanatic
Posts: 189
Joined: 2014-05-10, 18:19
Location: UK

Re: Strange behaviour of DomParser in a module

Unread post by thosrtanner » 2019-02-07, 20:33

vannilla wrote:
thosrtanner wrote:firstly that const is in a module, so won't, as I understand it, affect the global namespace.
I believe what Moonchild is trying to say is unrelated to the namespace.
I'm not clear what he is trying to say, sorry
Anyway, have you tried building the DOMParser using different methods? https://developer.mozilla.org/en-US/doc ... IDOMParser
I really can't see what parameters I could usefully pass to the init method

thosrtanner
Fanatic
Fanatic
Posts: 189
Joined: 2014-05-10, 18:19
Location: UK

Re: Strange behaviour of DomParser in a module

Unread post by thosrtanner » 2019-02-09, 09:51

This XML file is sufficient to trigger the issue

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<RSS>
<GROUP xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" url="http://example.com/feed/"/>
</RSS>
Scratchpad seems to be working in a context where DOMParser() is available for use and it's fine with it.

In the actual code, I read in the file and then convert the resultant string to utf8 with convertStringToUTF8.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 23234
Joined: 2011-08-28, 17:27
Location: 58°2'16"N 14°58'31"E
Contact:

Re: Strange behaviour of DomParser in a module

Unread post by Moonchild » 2019-02-09, 10:18

You're trying to embed XUL inside an RSS feed? that's not supported.
Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

thosrtanner
Fanatic
Fanatic
Posts: 189
Joined: 2014-05-10, 18:19
Location: UK

Re: Strange behaviour of DomParser in a module

Unread post by thosrtanner » 2019-02-09, 18:02

Moonchild wrote:You're trying to embed XUL inside an RSS feed? that's not supported.
I'm /not/ trying to. That's not an RSS feed in any case. it's a cut down version of the configuration file. And I'm still confused as to why the DOMParser from the main window happily accepts it whereas the one I instantiated inside a module says its an XML error. It is after all perfectly valid XML

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 23234
Joined: 2011-08-28, 17:27
Location: 58°2'16"N 14°58'31"E
Contact:

Re: Strange behaviour of DomParser in a module

Unread post by Moonchild » 2019-02-10, 15:24

thosrtanner wrote:It is after all perfectly valid XML
Sorry, but no, it is not. It might be well-formed, but it is most definitely not valid.
Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

thosrtanner
Fanatic
Fanatic
Posts: 189
Joined: 2014-05-10, 18:19
Location: UK

Re: Strange behaviour of DomParser in a module

Unread post by thosrtanner » 2019-02-10, 20:53

Why is it not valid? and if it is not valid, why is it accepted from the main code using the global DOMParser and not when using the DOMParser instantiated in a module?

yami_
Lunatic
Lunatic
Posts: 427
Joined: 2018-04-26, 11:05

Re: Strange behaviour of DomParser in a module

Unread post by yami_ » 2019-02-10, 21:07

I do not know the details but behavior of nsIDOMParser may be undefined when dealing with something it was not designed for.
cat came back from Berkeley waving flags -- rob pike

thosrtanner
Fanatic
Fanatic
Posts: 189
Joined: 2014-05-10, 18:19
Location: UK

Re: Strange behaviour of DomParser in a module

Unread post by thosrtanner » 2019-02-10, 22:19

yami_ wrote:I do not know the details but behavior of nsIDOMParser may be undefined when dealing with something it was not designed for.
That is a very loose statement. I'm feeding it XML (which I'm pretty sure it was designed for) and attempting to get a DOM structure. The xml is syntactically valid and somehow it is taking offense at the tag.

yami_
Lunatic
Lunatic
Posts: 427
Joined: 2018-04-26, 11:05

Re: Strange behaviour of DomParser in a module

Unread post by yami_ » 2019-02-10, 22:52

Actually it seem that this is intended behaviour:
The parsing error is correct for now; you can't use XUL from untrusted content anymore.
See comment #2 of bug #592829.
cat came back from Berkeley waving flags -- rob pike

User avatar
JustOff
Localization Coordinator
Localization Coordinator
Posts: 1727
Joined: 2015-09-03, 19:47
Location: UA
Contact:

Re: Strange behaviour of DomParser in a module

Unread post by JustOff » 2019-02-11, 00:01

Here is a possible workaround (checked in Scratchpad):

Code: Select all

var str = `<?xml version="1.0" encoding="UTF-8"?>
<RSS>
<GROUP xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" url="http://example.com/feed/"/>
</RSS>`;

var myDOMParser = new Components.Constructor("@mozilla.org/xmlextras/domparser;1", "nsIDOMParser");
var SecMan = Components.classes["@mozilla.org/scriptsecuritymanager;1"].getService(Components.interfaces.nsIScriptSecurityManager);
var ppal = SecMan.getSystemPrincipal();
var parser = new myDOMParser();
parser.init(ppal);
var doc = parser.parseFromString(str, "application/xml");
console.log(doc.children);
Here are the add-ons I made in a spare time. That was fun!

thosrtanner
Fanatic
Fanatic
Posts: 189
Joined: 2014-05-10, 18:19
Location: UK

Re: Strange behaviour of DomParser in a module

Unread post by thosrtanner » 2019-02-11, 20:30

Ohh. I see. Thanks, both.

I think honestly I might cheat and just rip the tag out of the string, as it serves no purpose (and I can only presume an earlier incarnation of something decided it needed to flag it as such).

Post Reply