[whatwg] Form-associated elements and the parser

[Adam Klein]

On Tue, Aug 6, 2013 at 4:47 PM, Adam Klein <adamk at chromium.org> wrote:
> On Tue, Aug 6, 2013 at 4:38 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> 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.
>
> My concrete proposal would be something like this:
>
> In step 4 of http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#create-an-element-for-the-token,
> add a requirement that "intended parent" and the "form element
> pointer" be part of the same "home subtree" (defined at
> http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#home-subtree).

For what it's worth, we're giving this a try in Blink
(https://src.chromium.org/viewvc/blink?revision=155949&view=revision),
as it's by far the safest fix for the related crashes. I'll update
this thread if we run into any compat issues in the wild (or if we
don't!).

- Adam

>> 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.
>
> This is basically the same thing Blink & WebKit do, with the caveat
> that we also avoid associating <form>s with elements inside
> <template>s (this is now reflected in step 4 of the algorithm, see
> above).
>
>> On a related note, when are you guys going to add a cycle collector or
>> other not-plain-refcounting memory manager :-)
>
> Yes, that would be nice :)
>
> - Adam
>
>> / 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