1. Open the attached example.
2. Open the inspector.
3. Make sure the #final_container element is visible in the DOM tree.
4. Click the "Test" button.
#element should move under the #final_container.
#element disappears from the DOM tree.
The test attaches to #element's DOMNodeRemoved event. When the handler is triggered it will move the element inside #final_container.
Created attachment 215526 [details]
This is the error I see in the console.
Release/WebInspectorUI.framework/Resources/DOMNode.js:553: JS ERROR: TypeError: undefined is not an object (evaluating 'node.parentNode = null')
(In reply to comment #4)
> Nice catch!
The problem is that the API will send two removal notifications for the same node. The first one will "unbind" it, so the second one will just have a nodeId === 0.
I guess we need to fix both the API and the JS side as the inspector should be backwards compatible.
Blink seems to have the same issue, just that their JS will recover from the error. The next message will just reinsert #final_container and all its children, so the #element gets fixed.
The content flow API I've just added has the same issue. It sends a nodeId === 0 when the node is removed from the DOM. That's because the node is unbound first and then the new API will just fallback to nodeId === 0.
I've just filed another one related to iframes. Nothing to do with the inspector. https://bugs.webkit.org/show_bug.cgi?id=123529
It all seems to be related to the fact that the node removal notification comes before related JS events execute. The C++ after it will abort the removal if the node has changed the parent, but, there are a couple of things that still happen anyway. For example frames are disconnected even though the element was just moved somewhere else.
Created attachment 216073 [details]
Adding fix for the protocol issue.
Comment on attachment 216073 [details]
Clearing flags on attachment: 216073
Committed r158708: <http://trac.webkit.org/changeset/158708>
All reviewed patches have been landed. Closing bug.