MutationObserver observed element removal

[bobOnGitHub]

Currently, with MutationObservers, to catch a node being removed from the DOM you have to observe the entire DOM and check every node removal record for the node in question.

( If you observe a node and remove that node nothing fires. The same applies to it's parent and so on all the way up to the document eg . https://stackoverflow.com/q/44935865/4779501 )

This is obviously extremely inefficient - possibly to the point of being unworkable in some cases.

An event on the MO, to fire when the element being observed is removed, would be one way to address this.

[annevk]

This seems like a duplicate of #533, no?

[bobOnGitHub]

Hey annevk, that all sounds very involved.

This differs from #533 in that I am interested specifically and only in MutationObservers ( not custom elements or general state of connectedness ) ;

My use case is with browser extensions / addons which need to know what is going on with existing 3rd party nodes on the page (without modifying them) so custom elements don't solve my problem(s). If I'm watching for changes and the node gets removed I don't know and have no way of "keeping house" (eg. when am I no longer managing the/any node(s) and in a position to respond to that).

As mentioned, doing document.contains(node) is not ideal, if even practical (depending on the page)- "things to observe" is everything - every removal has to be checked while I have any nodes of interest.

This shouldn't be difficult to implement or have any significant issues ; at the point in the code where the node is added/removed, for any observers attached to the node (in it's observers list), if there's a connected/disconnected event function on the observer call it.

For anyone not using MutationObservers it should have little to no effect. For those who want to use it ( and there are obviously some) it'll have the least overhead for their application.

( If there's a disconnect function on the node then it should be possible to do it with zero performance overhead where MOs not observing the node)

[annevk]

Well, we're not going to have multiple APIs for connectedness I think. So if we're not duping these they at least depend on each other.

[bobOnGitHub]

I think I see what you mean ; you could just have node connected/disconnect events as you do on custom elements which'd cover this and some or all of what's being discussed in #533..

[bobOnGitHub]

Yeah, duplicate of #533