Re: DOMParser RFE issues

Alex Vincent wrote:
> First, the expat parser loves to spew XML well-formedness errors 
> directly to the JS console.

Actually, it's the XML content sink that does this.  We probably do want to have 
a way to config this off for editors, yeah...

> Second, parsererror elements live in the null namespace.  So if there's 
> a person who is nutty enough to edit a XML document with a root element 
> of parsererror, I have no way of knowing that it's a real document.

There's an existing bug for better error reporting from DOMParser.

> Third, when I was doing my research for this, I noticed 
> nsExpatDriver::HandleError() returns NS_ERROR_HTMLPARSER_STOPPARSING...
> and no one checks the return value.

The method could probably be void.  The one caller already returns the right 
thing (NS_ERROR_HTMLPARSER_STOPPARSING).

> I'm wondering how to make expat (and my use of DOMParser) a little better.

None of this code is part of expat, fwiw.

> In addition, because I don't want to affect how mainline Mozilla code 
> uses these applications (the XML well-formedness error is useful as-is 
> to others), I'd wonder how to architecturally do it in a way that didn't
> regress current behavior.

Most simple would be a property on DOMParser that can be toggled and an API 
extension to nsIContentSink, I would guess.

A different component might work too; you'd basically need to implement your own 
XML sink then -- one that just ignores all the callbacks except the 
error-reporting one.  That would save you having to construct the DOM too, so 
maybe it's the way to go.

-Boris