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

Boris Zbarsky bzbarsky at MIT.EDU
Mon Aug 26 18:35:41 PDT 2013

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.

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.

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....  :(

> 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.


More information about the whatwg mailing list