[whatwg] Form-associated elements and the parser

[Jonas Sicking]

On Tue, Aug 6, 2013 at 4:27 PM, Adam Klein <adamk at chromium.org> wrote:
> On Tue, Aug 6, 2013 at 4:21 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> As I recall it (it was ages since I dealt with this), the tricky case
>> that you need to handle is this one:
>>
>> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2432
>>
>> In this case, web compatibility requires that the <input> is
>> associated with the form. Specifically hidden <input> elements would
>> often end up moved, but still had to show up in form.elements as well
>> as get submitted along with the form.
>
> That case definitely makes sense to me, and I think it's fine to keep
> that behavior for compat. The only one I'm asking to change is the
> case when the <input> and <form> end up in different trees.

Sure, as long as you come up with a formalized algorithm for when
there is an association and when there isn't. Keep in mind that by the
time that the input-element is inserted, the form-element might have
been moved elsewhere. We likely don't need the association in that
case, but detecting that that has happened sounds tricky.

The way that Gecko currently works IIRC is that it creates the
association any time it has seen a "<form>" without seeing a
"</form>". And it breaks the association anytime an input-element's
parent chain changes and the associated form-element is no longer in
the parent chain.

On a related note, when are you guys going to add a cycle collector or
other not-plain-refcounting memory manager :-)

/ Jonas

>> On Tue, Aug 6, 2013 at 2:01 PM, Adam Klein <adamk at chromium.org> wrote:
>>> Hixie opened my eyes last week to parser-association behavior of the
>>> sort found at http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2428.
>>> In that case, an <input> in a detached tree is associated with a
>>> <form> in the main document. This causes badness in WebKit and Blink
>>> because the association between the <form> and the <input> (e.g., as
>>> exposed in the HTMLFormElement.elements collection) is only weakly
>>> held to avoid reference loops (and thus memory leaks). And that
>>> weakness occasionally results in crashes when one of these objects is
>>> collected before the other.
>>>
>>> While all modern HTML parser implementations I tested seemed to agree
>>> on their treatment of the above example (they all return "1" as
>>> elements.length), this feature doesn't strike me as terribly useful.
>>> And for what it's worth, it doesn't seem to be present in legacy IE.
>>>
>>> I'm interested what others would think about changing the parser to
>>> only associate a <form> with an <input> if both are in the same "home
>>> subtree" (http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#home-subtree).
>>> Or is there some deep web-compat reason for this parsing oddity?
>>>
>>> - Adam