On Tue, Aug 6, 2013 at 4:47 PM, Adam Klein <ad...@chromium.org> wrote: > On Tue, Aug 6, 2013 at 4:38 PM, Jonas Sicking <jo...@sicking.cc> wrote: >> On Tue, Aug 6, 2013 at 4:27 PM, Adam Klein <ad...@chromium.org> wrote: >>> On Tue, Aug 6, 2013 at 4:21 PM, Jonas Sicking <jo...@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 <ad...@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
