DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24310>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24310 Document.replaceChild calls listeners during invalid state Summary: Document.replaceChild calls listeners during invalid state Product: Xerces2-J Version: 2.5.0 Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: DOM AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When using Document.replaceChild to replace the root element, MutationEvent listeners that are attached to the Document itself receive two events, in this order: new element inserted, old element removed. When the first event is fired, the document has two direct children that are elements, which is an invalid state for a DOM to be in. Another really bad side effect of the implementation in CoreDocumentImpl.replaceChild is that the cached document element is not updated until after the replacement is complete and the mutation event listeners are notified of both the insertion and removal. This means that those listeners, if they happen to call getDocumentElement(), will get the old root element in both cases. This is extremely confusing. I believe the correct behavior for Document.replaceChild is: 1) Remove old root element, firing node_removed event. During this event delivery, I think getDocumentElement should return the about-to-be-added new root, even though it is not get a child of the document. 2) Add the new root element, firing node_added event. The behavior of replaceChild for other nodes could keep the current order or not -- it doesn't matter whether remove happens before insert there, since both intermediate states are valid. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
