This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23534 - freeze/seal/preventExtensions should throw for Nodes (and maybe any WebIDL interface)
Summary: freeze/seal/preventExtensions should throw for Nodes (and maybe any WebIDL in...
Status: NEW
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 20567
  Show dependency treegraph
 
Reported: 2013-10-16 16:29 UTC by Bobby Holley (:bholley)
Modified: 2018-03-22 18:20 UTC (History)
5 users (show)

See Also:


Attachments

Description Bobby Holley (:bholley) 2013-10-16 16:29:18 UTC
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.
Comment 1 Anne 2013-10-16 16:37:50 UTC
Domenic suggested an alternative: if changing the prototype throws because the object is extension-prevented, we could just bubble that exception from adopt.
Comment 2 Bobby Holley (:bholley) 2013-10-16 17:07:22 UTC
(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.
Comment 3 Anne 2016-09-13 12:09:07 UTC
Duplicate of bug 26490 I think?
Comment 4 Boris Zbarsky 2016-09-13 14:57:39 UTC
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.
Comment 5 Anne 2016-09-13 15:01:15 UTC
Oh, that's still not decided upon? I thought we basically just disabled this for all platform objects...
Comment 6 Boris Zbarsky 2016-09-13 15:05:56 UTC
No, not at all.  Whyever would we do that?
Comment 7 Anne 2018-03-22 18:20:11 UTC
I'm no longer convinced we should pursue this.