Steps to reproduce: 1. Launch Mozilla. 2. Navigate to the following testcase. <!DOCTYPE test SYSTEM "notexist.dtd"> <test>a&foo;b</test> Actual result: "&foo;" will be silently ignored without any indication. Expected result: We should indicate that we could not replace "&foo;", or we should indicate that we could not locate the DTD.

Accepting bug and setting target milestone to M17...

This is a valid bug. Marking nsbeta3...

correctness of XML content handling.

-> Future, nsbeta3-, helpwanted (this is nisheeth in trudelle's cube). Seems like this is an edge case that has an easy workaround - supply the dtd referenced in the doctype.

Unfortunately, I can't supply DTD until bug 22942 is fixed.

This is a very serious error from the point of view of XML parsing rules.

Let's see if I can do something about this before "Future"... ;)

In xmlparse.c line ~2316 Expat detects DOCTYPE close. "dtd.complete && hadExternalDoctype" is true, so dtd.complete is set to false. It then checks if there is an external entity reference handler, which we have provided. Expat calls our handler expecting us to read the external DTD, WHICH WE DO NOT DO (except for chrome)!, but we say everything went ok, please continue. Later, around line ~1250 Expat realizes there is no entity declaration for the entity, but before returning an error it checks "dtd.complete || dtd.standalone" which turns out to be false (we never read the DTD to make it "complete"). I am wondering if this could be fixed by not doing any elaborate checks and returning error if there is no entity ref, period.

The attached patch seems to work. In our synchronous loading situation I feel we should be safe. I fixed another case which looked dubious in the same way, and noticed there is one place where Expat is doing exactly what I am doing (but there is a comment wondering what to do if dtd.complete value is this or that). I don't understand how not having the entity at hand could not be an error...

Ok, I feel like this could go in now that we have handling for XHTML entities. (And for MathML and SVG entities when those extensions are enabled.) I've asked harishd to review.

If an external entity is not loaded then propagate that message back to expat parser so that it can fail gracefully.

Comment on attachment 66394 [details] [diff] [review] patch v1.1 r=heikki I think this is a safer way to fix this.

Comment on attachment 66394 [details] [diff] [review] patch v1.1 Humm, I changed my mind. Need to think some more and do some testing...

I added the XML declaration and tested with different values of standalone. IE6 always reports that it cannot find the DTD. IE6 has validating parser so it must do this, as far as I understand. Mozilla reports the undefined entity foo error if standalone="yes". By default it is standalone="no", in which case we do not currently report an error, which is what this bug is about. Now what is the correct thing for a non-validating parser to report: could not load the DTD or no entity defined? I think no entity defined. Anyway, I presented this question to XML-DEV. Let's see what people say...

This one is basically patch one, which also fixes a minor perf issue and a real bug regarding errors in external entities (currently we do not report errors in external entities).

Comment on attachment 66486 [details] [diff] [review] Patch 1 with other fixes sr=jst

Fixed.

I still think there is an issue with external entities. Whatever the spec may say, external entities are being used, even by W3C folks, in real world documents. For example, I cannot read the XML SOAP spec with Mozilla 1.1, because the SOAP spec uses external entities (and Mozilla doesn't seem to fetch the corresponding DTDs first). I (and other folks) would really appreciate if this was fixed. Examples: - http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.xml - http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.xml

verified fixed on trunk build 2002-12-12-08-trunk on win2k with the testcase under comment #1 , for which the parser reports the error as undefined entity marking verified

Er, reopening. I thought we were a non-validating processor? From http://www.w3.org/TR/REC-xml#wf-entdeclared "Note that if entities are declared in the external subset or in external parameter entities, a non-validating processor is not obligated to read and process their declarations; for such documents, the rule that an entity must be declared is a well-formedness constraint only if standalone='yes'." So why is this "a very serious error from the point of view of XML parsing rules"?

Speaking from the point of view of a web-designer this issue is the only one that prevents me from making Firefox 0.9 my default browser. IE (spit!) makes developing XSLT stylesheets much more interactive, and my documents are littered with entity references. A note on the title of this bug: Firefox does not even look for an external DTD. I find talk above of mozilla being a non-validating parser most peculiar considering how useful this is to developers. Micro$oft even provide a validation script/page that may be installed locally and this could easily form the basis of an extension if the components supported it. The result: an XSLT development platform, and faster turnaround for designers.

I'm going to back out this fix to fix bug 204102, and this bug will be fixed by 346444.

No longer silently ignored.