Hi Boris, It seems you're right (reproduced on Chrome and Safari). These examples clearly violate all the invariants related to non-configurable properties.
If I understand correctly, the form DOM element's named input properties 'shadow' the actual JS properties defined on the DOM object. Even if the DOM object defines a non-configurable "foo" property, adding an input element with the name "foo" will shadow the non-configurable property with a configurable one (and removing the input element again reveals the old non-configurable JS property). This seems bad. I'm not a DOM expert, but is it essential that the form elements have two distinct namespaces (the namespace for named input elements and for regular JS properties), or is this just a side-effect of how they happen to be implemented? Regards, Tom 2014-07-28 18:04 GMT+02:00 Boris Zbarsky <bzbar...@mit.edu>: > I was trying to determine what browsers do with named properties on <form> > elements, and I'm getting some rather strange results. > > Consider https://bugzilla.mozilla.org/attachment.cgi?id=8463423 and > https://bugzilla.mozilla.org/attachment.cgi?id=8463432 > > Is it just me, or do Chrome and IE violate the internal method invariants > on the first of those, and all three of Chrome, IE, Safari violate them on > the second one? > > -Boris > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
