Violations of internal method invariants?
bzbarsky at MIT.EDU
Wed Jul 30 23:23:00 PDT 2014
On 7/31/14, 1:53 AM, Tom Van Cutsem wrote:
> If I understand correctly, the form DOM element's named input properties
> 'shadow' the actual JS properties defined on the DOM object.
That certainly seems to be what some UAs do, yes.
> 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?
That's an interesting question.
Gecko has totally different behavior here (we don't allow the form's
named inputs to shadow own properties of the form if someone managed to
define those, but will throw if you try to define a property for whose
name we already have a named input.
And the Web IDL spec has yet another approach to this whole thing: It
simply coerces "configurable" to true in its custom
[[DefineOwnProperty]] for these sorts of objects (but keeps effectively
I believe that the one shared feature between Gecko, the spec, and the
IE/Chrome implementation is that if you set a property "foo" on the
form, then add an input with name="foo", then remove the input, the
value you set initially will still be there. Actually, the same is true
in Safari, as long as you don't observe "form.foo" while the input is in
Requiring a single namespace, such that adding an input and then
removing it would make a previous property with the same name as the
input go away, would actually be fairly annoying performance-wise, I
In any case, I would be very interested in figuring out what sane
(sane-enough?) behavior UAs are willing to converge on here so we can
actually spec it.... If anyone has suggestions for what that behavior
should be, I'd love to hear them. Since every UA except Gecko certainly
needs to change _something_ here no matter what, seems like we might as
well all change in the same direction.
More information about the es-discuss