W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2013

[Bug 23534] freeze/seal/preventExtensions should throw for Nodes (and maybe any WebIDL interface)

From: <bugzilla@jessica.w3.org>
Date: Wed, 16 Oct 2013 17:07:22 +0000
To: public-script-coord@w3.org
Message-ID: <bug-23534-3890-v3MW5MRZrN@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23534

--- Comment #2 from Bobby Holley (:bholley) <bobbyholley@gmail.com> ---
(In reply to Anne from comment #1)
> Domenic suggested an alternative: if changing the prototype throws because
> the object is extension-prevented, we could just bubble that exception from
> adopt.

This could work. However, I'm generally uneasy about it.

There are various places in internal Gecko algorithms where we need to munge
the prototype - node reparenting, document.open, plugins, XBL, window
navigation, etc. A lot of this is really delicate and sensitive code, and we
can't afford to fail once we start. In the reparenting code, for example, we
just crash if we encounter a failure partway through. We can't let script
trigger that at will.

Theoretically, we could spec all the cases where this needs to happen, and
carefully check this state before we get ourselves into one of those tights
spots. But that's a pain, and a lot of effort to get right.

As an implementor, I'd prefer to spec that this stuff just throws. This doesn't
prevent someone from writing a DOM.js implementation that does something
different in that case, because the web is very unlikely to start depending on
things throwing. If that DOM.js implementation is viable modulo issues like
this one, I'm totally happy to respec to allow this kind of stuff. But I'm not
really wild about putting in engineering effort widening attack surface for
unproven gains.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Wednesday, 16 October 2013 17:07:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:18 UTC