Closed Bug 267350 Opened 15 years ago Closed 2 years ago
Ignores XMl entity declarations which appear in the internal subset of a DTD after an external parameter entity (declaration+reference)
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)
-->Browser: Firefox doesn't have its own XML parser.
Assignee: firefox → core.xml
Component: General → XML
Product: Firefox → Browser
QA Contact: firefox.general → ashshbhatt
Version: unspecified → Trunk
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.
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...
Status: UNCONFIRMED → NEW
Depends on: entities
Ever confirmed: true
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.)
The test cannot be loaded and OP doesn't describe the bug in a way I can reproduce without the test.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.