267350 - Ignores XMl entity declarations which appear in the internal subset of a DTD after an external parameter entity (declaration+reference)

Status: RESOLVED INVALID

(Core :: XML, defect)

Description

[Heinz W. Werntges]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10

Load the XML document at the given URL. You'll see an 
"XML Parsing Error: undefined entity" in line 53, column 12
about entity reference &Ae; which actually is properly declared.

Load the source code and read the comments for the details.

Move the entity declaration above the parameter entity ("agr") lines
and it will work! However, according to the XML 1.0 specifications,
all entity declarations within the internal subset should be understood,
independent of position in the file.

Finally, it would be great to add support for external entities to
Mozilla/Firefox support (see commments in source code).

Reproducible: Always
Steps to Reproduce:
1. Load doc at URL given above
2. Observe error message regarding entity ref. &Ae;
3. Load document source for more details

Actual Results:  
XML Parsing error when referencing &Ae;

Expected Results:  
1) Accept (expand) &Ae; just as in the case of &ae;
2) Report Parsing error only upon occurrence of &agr;
3) Better still: Expand external parameter entity ref %iso-grk1; in DTD,
   also accept & expand &agr;


MS IE 6.0 apparently handles the reported cases correctly (sorry, folks...)

Bug appears on all encountered Windows / Linux platforms
and for quite a while (Mozilla 1.0 + (?) thru Firefox 1.0 preview release)

Comment 1

[Phil Ringnalda (:philor)]

-->Browser: Firefox doesn't have its own XML parser.

Comment 2

[Bob Clary [:bc] (inactive)]

the use of the external parameter entity causes the Ae entity to not be defined.
Removing %iso-grk1; fixes the problem. It looks like we stop reading the
internal definitions once the external entity is seen. 

Comment 3

[Boris Zbarsky [:bzbarsky]]

So the issue is that the external entity handler in the expat driver returns an
error to expat if the entity cannot be loaded (say it's not chrome).

Expat, upon getting such an error, immediately aborts further processing of the
DTD.  I'm not sure why it doesn't abort parsing of the file altogether....

The simple solution is to return a success result to expat for this case, while
ignoring the external entity as we do now.  Though we should watch out for
things like bug 35984...

Comment 4

[Brett Zamir]

Cross-posting on relevant bug pages:

For this bug, and a number of other associated bugs (Bug 204102, Bug 267350, Bug 22942, and to a lesser extent Bug 196355), I've started a pledge drive at http://pledgie.com/campaigns/7732 to try to hire a developer(s) who can work with the Mozilla devs (if they are ineligible themselves) to get these long-standing and niche but important-to-XML-users bugs fixed. Feel free to make a pledge to donate toward these fixes or, if you are a developer, make a bid in the comments there to offer to fix, in conjunction with Mozilla devs, this or any of the other aforementioned XML-related bugs/feature requests. 

(If we can get enough momentum, Bug 234485, Bug 98413, Bug 275196, and Bug 94270 might be also nice candidates to get addressed too, but I've started with the (single-point-of-failure-causing) DTD issues.)

Comment 5

[Anne (:annevk)]

The test cannot be loaded and OP doesn't describe the bug in a way I can reproduce without the test.