Strange behaviour of DomParser in a module

General discussion, compatibility and contributed extensions.

Moderators: satrow, Lootyhoof, FranklinDM

thosrtanner
Fanatic
Fanatic
Posts: 172
Joined: Sat, 10 May 2014, 18:19
Location: UK

Strange behaviour of DomParser in a module

Unread postby thosrtanner » Tue, 05 Feb 2019, 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: 1662
Joined: Thu, 03 Sep 2015, 19:47
Location: UA
Contact:

Re: Strange behaviour of DomParser in a module

Unread postby JustOff » Tue, 05 Feb 2019, 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: 22828
Joined: Sun, 28 Aug 2011, 17:27
Location: 58°2'16"N 14°58'31"E
Contact:

Re: Strange behaviour of DomParser in a module

Unread postby Moonchild » Wed, 06 Feb 2019, 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: 172
Joined: Sat, 10 May 2014, 18:19
Location: UK

Re: Strange behaviour of DomParser in a module

Unread postby thosrtanner » Wed, 06 Feb 2019, 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: 172
Joined: Sat, 10 May 2014, 18:19
Location: UK

Re: Strange behaviour of DomParser in a module

Unread postby thosrtanner » Wed, 06 Feb 2019, 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: 254
Joined: Sat, 05 May 2018, 13:29

Re: Strange behaviour of DomParser in a module

Unread postby vannilla » Thu, 07 Feb 2019, 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: 172
Joined: Sat, 10 May 2014, 18:19
Location: UK

Re: Strange behaviour of DomParser in a module

Unread postby thosrtanner » Thu, 07 Feb 2019, 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: 172
Joined: Sat, 10 May 2014, 18:19
Location: UK

Re: Strange behaviour of DomParser in a module

Unread postby thosrtanner » Sat, 09 Feb 2019, 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: 22828
Joined: Sun, 28 Aug 2011, 17:27
Location: 58°2'16"N 14°58'31"E
Contact:

Re: Strange behaviour of DomParser in a module

Unread postby Moonchild » Sat, 09 Feb 2019, 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: 172
Joined: Sat, 10 May 2014, 18:19
Location: UK

Re: Strange behaviour of DomParser in a module

Unread postby thosrtanner » Sat, 09 Feb 2019, 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: 22828
Joined: Sun, 28 Aug 2011, 17:27
Location: 58°2'16"N 14°58'31"E
Contact:

Re: Strange behaviour of DomParser in a module

Unread postby Moonchild » Sun, 10 Feb 2019, 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: 172
Joined: Sat, 10 May 2014, 18:19
Location: UK

Re: Strange behaviour of DomParser in a module

Unread postby thosrtanner » Sun, 10 Feb 2019, 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: 328
Joined: Thu, 26 Apr 2018, 11:05

Re: Strange behaviour of DomParser in a module

Unread postby yami_ » Sun, 10 Feb 2019, 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: 172
Joined: Sat, 10 May 2014, 18:19
Location: UK

Re: Strange behaviour of DomParser in a module

Unread postby thosrtanner » Sun, 10 Feb 2019, 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: 328
Joined: Thu, 26 Apr 2018, 11:05

Re: Strange behaviour of DomParser in a module

Unread postby yami_ » Sun, 10 Feb 2019, 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: 1662
Joined: Thu, 03 Sep 2015, 19:47
Location: UA
Contact:

Re: Strange behaviour of DomParser in a module

Unread postby JustOff » Mon, 11 Feb 2019, 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: 172
Joined: Sat, 10 May 2014, 18:19
Location: UK

Re: Strange behaviour of DomParser in a module

Unread postby thosrtanner » Mon, 11 Feb 2019, 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).


Return to “Browser extensions”

Who is online

Users browsing this forum: No registered users and 3 guests