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 <bzbarsky at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140731/0013409c/attachment.html>

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?