"reset the form owner" is not quite right

[annevk]

I looked into fixing bug 28800 (now moved to this issue), but I can't quite figure out what model browsers are actually using. For Live DOM Viewer:

<div><table><form><tr><td><input></table></div>
<div id=2></div>
<script>
w(document.querySelector("input").form)
document.getElementById("2").appendChild(document.querySelector(someElementName))
w(document.querySelector("input").form)
</script>

If someElementName is "div" or "table" the owner remains the same. If it is "form", "tr", or "input" it becomes null.

This is what HTML says about the matter (if we ignore the parser bits that cause the unusual association seen above and ignore the form attribute):

When a form-associated element or one of its ancestors becomes connected, then the user agent must reset the form owner of that form-associated element. The HTML parser overrides this requirement when inserting form controls.

When an element changes its parent node resulting in a form-associated element and its form owner (if any) no longer being in the same tree, then the user agent must reset the form owner of that form-associated element.

It seems however that when it is reset works very differently from that (and consistently so across at least Chrome, Firefox, and Safari).

Also, it doesn't seem like "connected" is correct, since as demonstrated by http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3537 that's not a requirement.

It would be great if someone could help me understand what browsers actually do here (and where that is located in the code).

cc @tkent-google @smaug----

[tkent-google]

The code in Chromium is here: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/ListedElement.cpp?type=cs&sq=package:chromium&l=77

ListedElement::InsertedInto is called after this element or its ancestor is inserted to insertion_point, and RemovedFrom is called after this element or its ancestor is removed from insertion_point.

[annevk]

Ah, so insertion checks a bit for "inserted by the parser". The specification has it as a special case that doesn't persist as a bit. And then I guess there's some other things.