DO NOT REPLY [Bug 24310] - Document.replaceChild calls listeners during invalid state

[bu...@apache.org]

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





------- Additional Comments From keshlam@us.ibm.com  2003-11-04 14:22 -------
This may or may not be desirable, but as far as I can tell it's not an error per
se. The DOM spec carefully avoided specifying the order in which events are
thrown in order to leave maximum room for optimization. I don't think there was
a promise that intermediate stages of compound operations such as replaceChild
were promised to be completely well-formed DOMs.

I do agree that special-casing Document, rather than using the general
Node.replaceChild(), might be appropriate. On the other hand, since there's no
guarantee what order any other DOM presents these in, I'd say code which is
counting on this specific sequence should probably be considered nonportable and
avoided when possible.

> 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.

Uhm. I can't find justification for doing that last in the DOM spec. This is
once again getting into areas which are going to be nonportable...

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org