DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=27119>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27119 Improper handling of elements in external entities ------- Additional Comments From [EMAIL PROTECTED] 2004-03-08 08:14 ------- I will attach a proposed patch for AbstractDOMParser.cpp The patch only affects the behavior when the fCreateEntityReferenceNodes flag has been set to false (not the default; the behavior in the default case is already correct as far as I know.). In that case, the startEntityReference method returns before creating a DOMEntityReference object. and endEntityReference returns immediately. The old behavior was to always create the DOMEntityReference and let the usual parsing process create element nodes, etc. which were its descendants. The whole thing was marked read-only but, not attached to the document. Instead, a cloned version (not read-only) was attached. However, the bookkeeping for ID attributes had already been done on the original elements created, hence getElementById would return a pointer to the wrong copy. Rather than attempt to fix up the bookkeeping, it seemed simpler and safer to just eliminate the duplicate and let the original creation of the elements be in the "right" place and with the right properties (not read-only). The patch fixes the problem demonstrated by the test program previously attached, however I make no guarantee that it doesn't cause some other problem somewhere else. Please check it out! Thanks. Joanne --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
