Re: Violations of internal method invariants?

On Thu, Jul 31, 2014 at 1:23 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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 suspect.

Really? There are web pages that add inputs to forms in a tight loop?

> 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.

Right Thing: I think [[PreventExtensions]] on these objects should
always return false. I think [[DefineProperty]] on these objects
should return false if Desc.[[Configurable]] is false or if it's
missing and would default to false. That'll cause Object.freeze(form)
and Object.defineProperty(form, "x", {configurable: false}) to throw a
TypeError. Seems legit.

Alternative: Specify what Gecko does. Make non-configurable properties
on these objects shadow even the named getter.

At the moment, I don't see anything else that would preserve the
object invariants.

-j

Received on Thursday, 31 July 2014 13:44:18 UTC