Message from JavaScript discussions
October 2017
— Today I discovered a mis-implementation of the DOM API in Webkit, and I need some help updating MDN to reflect this... mutative node-moving builtins (IE, appendChild, insertBefore etc...) incorrectly return the DocumentFragment when given one. The W3C specification states that these functions should move the child nodes of the DocumentFragment, and that they should also return the inserted nodes. I looked at the C++ source code for that function, and it seems to be developer error.
Both Chrome and Chromium use Webkit, as does Safari. Firefox uses Gecko which aims to mimic Webkit, and thus also has this behavior. It appears to be "standard", so it's not a bug but rather a "feature" at this point that can't really be fixed easily without possibly breaking code.
— I just need someone with access to Internet Explorer and Microsoft Edge to also reproduce this behavior. I have created a document that should do it if run in a browser.
— I just updated the appendChild and insertBefore pages. Still trying to track down all the bad code.
— Been digging around in the C++ source for webkit through Chromium's nice source code search tool... https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/ContainerNode.cpp?sq=package:chromium&dr=CSs&l=810
— Here's the code btw, it isn't actually checking whether or not it gets a DocumentFragment, it is literally just returning the first parameter it is given blindly. I somehow guessed this was the case before I saw the code, too. LOL
—
if (!CollectChildrenAndRemoveFromOldParent(*new_child, targets, exception_state))
return new_child;
— Reproducer
— Background is slideshow. For example, click create account which changes only the form, background remains the way. How it?
— Hi, good to know
— The spec says it inserts the children of the fragment, and that's what they do.
— It also says those functions return the inserted nodes.