Bug 247427 - Setting [[Prototype]] of global object in JSC shell should not throw `TypeError`
Summary: Setting [[Prototype]] of global object in JSC shell should not throw `TypeError`
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-11-03 08:51 PDT by Kanguk Lee
Modified: 2022-11-11 09:10 PST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kanguk Lee 2022-11-03 08:51:01 PDT
// input.js
Object . setPrototypeOf ( this , { } ) ;
__________________________________________

Hello,

Executing the input.js using JSC throws TypeError, but it is expected to terminate normally.

Running the input.js with JSC gives

---
$ jsc input.js
Exception: TypeError: Cannot set prototype of immutable prototype object
setPrototypeOf@[native code]
global code@input.js:1:24
---

while other engines behave like

---
# V8
$ node input.js
// no error

# GraalJS
$ js input.js
// no error
---


WebKit version: 615.1.10
Comment 1 Radar WebKit Bug Importer 2022-11-03 18:15:41 PDT
<rdar://problem/101940462>
Comment 2 Alexey Shvayka 2022-11-03 18:49:21 PDT
Great catch, thank you!

Indeed the ECMA-262 doesn't require global object to have immutable prototype; it's the WebIDL spec which makes global objects' [[Prototype]] slots immutable: https://webidl.spec.whatwg.org/#platform-object-setprototypeof. That shouldn't affect the JSC shell of course.

When fixing that we need to ensure that scope resolution is sane when `globalThis.__proto__` is modified, which might get a little tricky.
Comment 3 Yusuke Suzuki 2022-11-10 13:03:37 PST
I wonder if we should fix this. Since DOM window is super more common in various places, should we just keep our behavior aligned to DOM window?
Comment 4 Alexey Shvayka 2022-11-11 09:10:01 PST
(In reply to Yusuke Suzuki from comment #3)
> I wonder if we should fix this. Since DOM window is super more common in
> various places, should we just keep our behavior aligned to DOM window?

I would say we should fix this (not prioritize of course) just for the spec purity and non-browser environments like Bun, which claims to be functionally-equivalent to Node.js.