- From: Adam Klein <adamk@chromium.org>
- Date: Tue, 6 Aug 2013 16:47:35 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Kent Tamura <tkent@chromium.org>, WHATWG List <whatwg@whatwg.org>, Ryosuke Niwa <rniwa@webkit.org>
On Tue, Aug 6, 2013 at 4:38 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Tue, Aug 6, 2013 at 4:27 PM, Adam Klein <adamk@chromium.org> wrote: >> On Tue, Aug 6, 2013 at 4:21 PM, Jonas Sicking <jonas@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). > 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@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
Received on Tuesday, 6 August 2013 23:48:00 UTC