23534 2013-10-16 16:29:18 +0000 freeze/seal/preventExtensions should throw for Nodes (and maybe any WebIDL interface) 2018-03-22 18:20:11 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified PC All NEW P2 normal --- 20567 1 bobbyholley cam annevk bruant.d bzbarsky mike public-script-coord public-webapps-bugzilla oldest_to_newest 94849 0 bobbyholley 2013-10-16 16:29:18 +0000 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. 94850 1 annevk 2013-10-16 16:37:50 +0000 Domenic suggested an alternative: if changing the prototype throws because the object is extension-prevented, we could just bubble that exception from adopt. 94851 2 bobbyholley 2013-10-16 17:07:22 +0000 (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. 127374 3 annevk 2016-09-13 12:09:07 +0000 Duplicate of bug 26490 I think? 127378 4 bzbarsky 2016-09-13 14:57:39 +0000 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. 127379 5 annevk 2016-09-13 15:01:15 +0000 Oh, that's still not decided upon? I thought we basically just disabled this for all platform objects... 127380 6 bzbarsky 2016-09-13 15:05:56 +0000 No, not at all. Whyever would we do that? 129109 7 annevk 2018-03-22 18:20:11 +0000 I'm no longer convinced we should pursue this.