27017 2014-10-10 13:08:00 +0000 [Custom]: Constructor/prototype linkage needs to actually be defined, since it's dynamic, not static 2015-07-06 08:11:02 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED MOVED P2 normal --- 14968 1 bzbarsky dglazkov annevk gkrizsanits mike public-webapps public-webapps-bugzilla oldest_to_newest 112946 0 bzbarsky 2014-10-10 13:08:00 +0000 See https://bugzilla.mozilla.org/show_bug.cgi?id=1081037#c1 for an explanation of the issues. 112958 1 dglazkov 2014-10-10 16:22:39 +0000 (In reply to Boris Zbarsky from comment #0) > See https://bugzilla.mozilla.org/show_bug.cgi?id=1081037#c1 for an > explanation of the issues. > Specifically, all it says is: > Let CONSTRUCTOR be the interface object whose interface prototype object is PROTOTYPE > What this would normally mean in Web IDL is the following: CONSTRUCTOR.prototype == PROTOTYPE PROTOTYPE.constructor == CONSTRUCTOR > but these are static constraints in Web IDL, since the set of interfaces is fixed. Yep, that's exactly what it means. I could specify this in ES terms, rather than Web IDL, would that help? http://es5.github.io/#x13.2 > For the registerElement case, what happens if the same prototype is registered multiple times? What does its .constructor end up being? Futhermore, what should happen if the .constructor is non-configurable, or nonwritable, or both, before the registerElement call happens? Is the property set via Put() or via DefinePropertyOrThrow() or something else? This is already spec'd here: http://w3c.github.io/webcomponents/spec/custom/#dfn-custom-element-constructor-generation > I mean, in terms of implementation we can just JS_LinkConstructorAndPrototype and move on for now, but that may not give us the same behavior that Chrome has, and per spec the behavior is just not defined 112960 2 bzbarsky 2014-10-10 16:37:05 +0000 > Yep, that's exactly what it means. There's a difference. The Web IDL setup is about standard objects that are created as part of the initial scripting environment setup. Therefore it doesn't have to specify how the properties are actually set/added/whatever because it doesn't matter: none of the objects have any properties before the set/add, there are no page-defined things on the prototypes, etc. > This is already spec'd here: http://w3c.github.io/webcomponents/spec/custom/#dfn-custom-element-constructor-generation Ah, step 1? That covers it being already registered or having a non-configurable property named "constructor", but doesn't cover what should happen if it _is_ configurable. If the intent is that a [[DefineOwnProperty]] happens somewhere in here, that needs to be clearly specified. Especially because [[DefineOwnProperty]] can have side-effects, so you have to define how it's ordered with other things. Furthermore, you need to define exactly how one is supposed to determine "has a non-configurable property named constructor". I assume the intent is to do [[GetOwnProperty]] and then check the [[Configurable]] of the resulting property descriptor, but since this too can have side effects it's worth specifying exactly how and when it happens. 121697 3 hayato 2015-07-06 08:11:02 +0000 Moved to https://github.com/w3c/webcomponents/issues/190