DO NOT REPLY [Bug 24310] New: - 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

           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: xerces-j-dev@xml.apache.org
        ReportedBy: brian.stoler@oracle.com


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: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org