What if I pass null as principal to parser's init?
What all this fuss is about if a code (XPCOM component) already runs in privileged mode? It can access a whole lot of unsafe things. Such as Components.classes etc. It can erase files and eat my dog. So why can't it simply parse a piece of XML without piercing through superfluous obstacles?
BTW I could not find a sane documentation on nsIPrincipal concerning what it actually is and how it can be obtained.

> What if I pass null as principal to parser's init?
Then you'll get the untrusted behavior.
> What all this fuss is about
The assumption is that you're possibly parsing data you don't trust and don't want to give it chrome permissions by accident. So if you trust the data you're parsing, you need to explicitly say so.

(In reply to comment #10)
> > a web page will be unable to parse XML containig nodes in XUL namespace?
>
> At the moment, that is correct. There's some argument happening about it,
> though.
It's unlikely to be changed. Allowing nodes in the XUL namespace to be instantiated would be an enormous amount of work, both now and ongoing in the future. It does not appear that this amount of work will be worth it.

> > > a web page will be unable to parse XML containig nodes in XUL namespace?
> > At the moment, that is correct.
> It's unlikely to be changed.
This is unfair from my point of view. Parsing means just getting a DOM. This DOM does not necessary need to be "executed" (like displayings a XUL window). I understand that security is a primary objective, though disalowing to parse _some_ kinds of XML looks... weird. It reminds me a joke that it's a syntax error to write fortran code while not wearing a blue tie.

Thanks to the excellent testcase, this was indeed a trivial fix.
The basic problem is that we don't have very good error handling in the expat driver, which means that even after we've failed to parse the <overlay> start tag, we keep parsing. However since the state isn't what we expect it to be, we fall over.
Ideally we should revamp our XML parser error handling, but that's post-FF4 work.

I'm bumping this to beta8. There are *no* crashes in crash-stats with this signature so I don't think people are hitting it a lot.
An update on the patch: I landed it but it caused aborts. I know why it causes the abort, but when I fixed that problem, tryserver showed leaks which may or may not have been intermittent. Looking into that now.

This fixes two things:
1. Clears the mLoopingForSyncLoad flag if we error during parsing in the DOMParser. This avoids a debug-only abort in the DOMParser dtor
2. Collapse most error codes to NS_ERROR_HTMLPARSER_STOPPARSING in the expat driver so that we properly call Terminate() and thus avoid leaking if there are errors originating in the XML sink.
got r=peterv over irl

I was also asked to put this in beta7 if we had a fix in time. This fix feels very secure, especially compared to current m-c code. (Only reason it was backed out was due to test case exercising code that is already there).