[whatwg] Elements should be removed from the past names map once it's no longer associated with the form element

[Ryosuke Niwa]

On Aug 26, 2013, at 6:35 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 8/26/13 7:13 PM, Ryosuke Niwa wrote:
>> https://bug-120328-attachments.webkit.org/attachment.cgi?id=209688
>> IE10 passes all test cases but WebKit and Gecko fails 2nd, 4th, 6th, and 7th test cases.
> 
> You must be testing Firefox 23 or earlier?  Firefox 24 or later passes all these tests.

Yes, I was testing on Firefox 23 .

> In any case, the 2nd, 4th, 6th, and 7th tests are about properties not disappearing when they should, so those are not relevant here as far as I can tell.
> 
> That said, looking at this more closely, it seems like you and I may be in violent agreement.  Right now the spec says:
> 
>   If an element listed in the form element's past names map is removed
>   from the Document, then its entries must be removed from the map.
> 
> which is all the testcase above tests as far as I can tell, since it removes the control from the DOM after setting its @form.  The testcase doesn't test what happens when @form is set on a control without removing it from the DOM.

Thanks for pointing that out.  I somehow missed that statement.  I didn't test the case of explicitly setting the form content attribute because IE10 doesn't seem to support the form content attribute on input elements.

> What happens in Firefox 24 and above is that when an element stops being form-associated with a form it is in fact removed from the past names map for that form.  I asked for a spec bug to be filed to that effect in https://bugzilla.mozilla.org/show_bug.cgi?id=879319#c4 but I'm not sure that ever happened....  :(

That's good to hear.  So we're definitely in agreement with respect to this new behavior.

>> What I mean is the form content attribute of a form control element used as in: myInputInput.setAttribute('form', 'myForm');
> 
> Ah, I see.  Yes, ok.  So in particular, the spec already requires that elements be removed from the past names map when removed from the DOM, so the only issue is with @form changes, and there is not likely to be much content relying on @form changes _not_ removing from the past names map.  I wholeheartedly agree.

Yes, I'm particularly concerned about the case where form is explicitly changed.  With that, we can have an input element containing its owner form element, along with all other crazy edge cases.

It seems like Firefox 24 already implements the exact behavior I want in WebKit so I'll go ahead and try to change WebKit's behavior accordingly.

- R. Niwa