Normative: Restriction on [[Prototype]] of the global object

[jhnaldo]

According to the issue in Test262 repository, Test262 provides the following tests that assume that the global object is an instance of the built-in Object constructor:

• /test/built-ins/Object/defineProperty/15.2.3.6-4-625gs.js
• /test/built-ins/Object/getPrototypeOf/15.2.3.2-2-30.js
• /test/built-ins/decodeURI/S15.1.3.1_A5.5.js
• /test/built-ins/decodeURIComponent/S15.1.3.2_A5.5.js
• /test/built-ins/encodeURI/S15.1.3.3_A5.5.js
• /test/built-ins/encodeURIComponent/S15.1.3.4_A5.5.js
• /test/built-ins/eval/prop-desc-enumerable.js
• /test/built-ins/parseFloat/S15.1.2.3_A7.5.js
• /test/built-ins/parseInt/S15.1.2.2_A9.5.js
• /test/language/global-code/decl-lex.js

@ljharb said in the comment:

That seems somewhat like a spec issue to me than a test issue;
web reality is that the global inherits from Object.prototype,
so at least web browsers (Annex B) would have to have that be true.

Thus, I added one restriction to the global object which is "the global object should be an instance of the standard built-in Object constructor.

[bathos]

Is “is an instance of the standard built-in Object constructor” an observable status / a defined concept?

I’m guessing the intention here is to say that the [[Prototype]] chain (initially? permanently?) includes %Object.prototype%, which is not the same thing as being an instance of a given constructor as this phrase is used elsewhere. For example,

[A Boolean Object is] a member of the Object type that is an instance of the standard built-in Boolean constructor.

It’s observable (indirectly) that an object is a Boolean Object because the [[BooleanData]] slot is obtained uniquely through creation with the Boolean constructor. It’s incidental that such an object likely has %Boolean.prototype% as its [[Prototype]], and it may not — Object.setPrototypeOf(new Boolean, null) is still a Boolean Object.

[jhnaldo]

I agree with your opinion. The sentence "is instance of the the standard built-in Object constructor" does not clearly imply that the prototype chain includes %Object.prototype%. Thus, I just directly wrote that the prototype chain include %Object.prototype% and updated the pull request.

[devsnek]

this is normative, not editorial.

[jhnaldo]

this is normative, not editorial.

Thank you for the correction, I revised the name of the pull request.

[ljharb]

One of the challenges here might be that %Object.prototype% is a Realm-specific value, but i believe the WindowProxy causes the current realm's Object.prototype to report as being in the prototype chain.

[ExE-Boss]

WindowProxy.[[GetPrototypeOf]]() returns null for cross‑origin calls, which are a subset of cross‑realm calls.

[ljharb]

Right - and null doesn't have Object.prototype in its prototype chain.

[littledan]

Good catch! If it's not possible to make this assertion about all JS environments, another way to go about ensuring the accuracy of the tests would be to make a piece of metadata in the test262 tests indicating, "these tests are valid for environments where Object.prototype is in the prototype chain of the global object".

[ExE-Boss]

Well, within the realm of the global object, the global object’s prototype will always include %Object.prototype% in its prototype chain, it’s only for cross‑origin calls, which are a subset of cross‑realm calls that the WindowProxy will hide the prototype.

[littledan]

It's not really clear to me what an assertion like "the prototype chain includes" means when the prototype chain is queried by [[GetPrototypeOf]]().