[Custom]: Constructor/prototype linkage needs to actually be defined, since it's dynamic, not static (bugzilla: 27017)

[hayatoito]

Title: [Custom]: Constructor/prototype linkage needs to actually be defined, since it's dynamic, not static (bugzilla: 27017)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27017

---

comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27017#c0
Boris Zbarsky wrote on 2014-10-10 13:08:00 +0000.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1081037#c1 for an explanation of the issues.

---

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27017#c1
Dimitri Glazkov wrote on 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

---

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27017#c2
Boris Zbarsky wrote on 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.

[rniwa]

I don't think this issue exists anymore now that we're using author defined constructor. See the issue #403 for new construction algorithm.