This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Freezing an object or calling preventExtensions theoretically means that the prototype is fixed. But there are cases in the DOM when we need to modify the prototype. In particular, this is the case for Nodes when adopted into the scope of a different global (see bug 20567). jst and I think that we should just throw when trying to do any of these objects on any kind of WebIDL-defined object. Anne generally agrees, but there are some considerations about self-hosted DOMs to be considered.
Domenic suggested an alternative: if changing the prototype throws because the object is extension-prevented, we could just bubble that exception from adopt.
(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.
Duplicate of bug 26490 I think?
Not at all. Bug 26490 is about the spec mechanism we use to prevent sealing/freezing for the objects we prevent it for. This bug is about what objects we should prevent it for.
Oh, that's still not decided upon? I thought we basically just disabled this for all platform objects...
No, not at all. Whyever would we do that?
I'm no longer convinced we should pursue this.