[Bug 22320] Form's supported property names should perhaps not be enumerable

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22320

--- Comment #11 from Boris Zbarsky <bzbarsky@mit.edu> ---
> Backwards compat with what?

The main backwards compat requirement is that form.foo needs to return certain
things for certain values of foo.

There is probably a less important requirement that the expression |"foo" in
form| test true for certain values of "foo".

There is no backwards compat requirement on the behavior of
getOwnPropertyNames, obviously, since nothing on the Web uses it, to a first
approximation.

> Just because some browsers shipped a bug

More precisely, all those browsers implement these objects as something
proxy-like and did the simplest possible implementation they could that
satisfied the backwards compat requirements I outline above.  The simplest
implementation is to return [] from getOwnPropertyNames (though in actuality it
seems like they return [0, 1, 2, ...., length-1]).

> In other words, must they refuse Object.freeze, .seal, and .preventExtensions?

There is no explicit mention in the WebIDL spec of them behaving in interesting
ways with those.  WebIDL just defines the behavior of [[GetOwnProperty]] and
[[DefineOwnProperty]] on the objects and then things fall out from that (e.g.
Object.freeze is described mostly in terms of those internal methods).

> After they are made non-extensible, if they claim (via getOwnPropertyNames)
> not to have an own property, they must not after (e.g., by
> getOwnPropertyDescriptor) claim to have
> that property, or they would violate the non-extensibility contract.

I strongly suspect that actual browser implementations do all sorts of weird
stuff here.  And as far as I can tell, so can direct proxies...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 9 July 2013 07:36:18 UTC