On Aug 26, 2013, at 6:51 PM, Ryosuke Niwa <[email protected]> wrote: > > On Aug 26, 2013, at 6:35 PM, Boris Zbarsky <[email protected]> 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.
Oops, an input element containing its owner element is fine. What's not fine is the case where an input element contains a form element whose past names map points back to the input element and the input element's owner isn't the same form element. - R. Niwa
