Behavior of Window's [SetPrototypeOf] ?

[cdumez]

The HTML specification merely says to return false:
https://html.spec.whatwg.org/#windowproxy-setprototypeof

7.4.2 [[SetPrototypeOf]] ( V )

Return false.

However, this does not seem to match browsers?

Firefox:

• Cross-Origin: Throws an Error
• Same Origin: Throws a TypeError

Chrome:

• Cross-Origin: Throws a SecurityError
• Same Origin: Sets the prototype

Safari TP:

• Cross-Origin: Ignores and logs an error message
• Same Origin: Sets the prototype

[cdumez]

@annevk @domenic @bzbarsky

[cdumez]

http://w3c-test.org/html/browsers/origin/cross-origin-objects/cross-origin-objects.sub.html seems to expect that an exception be thrown for the cross-origin case.

[bzbarsky]

However, this does not seem to match browsers?

It matches Firefox for the same-origin case, no? At least assuming you're using Object.setPrototypeOf: http://www.ecma-international.org/ecma-262/6.0/#sec-object.setprototypeof step 7 says to throw a TypeError if O.[[SetPrototypeOf]] returns false.

Chrome hasn't updated to this part of the spec yet, sounds like; it's a somewhat recent change to the spec (both HTML and ES; see https://tc39.github.io/ecma262/#sec-immutable-prototype-exotic-objects-setprototypeof-v and https://tc39.github.io/ecma262/#sec-properties-of-the-object-prototype-object which makes trying to set the prototype of Object.prototype throw in the same way). The idea is to make the prototype chain of the global immutable in general.

For the cross-origin case, this is a matter of the clear WindowProxy spec being fairly new and hence Firefox not yet implementing it. We should change the test to test that a TypeError is thrown, probably....

[annevk]

After web-platform-tests/wpt#3610 lands I can update the (cross-origin) test to actually check for specific exceptions. Okay with you @bholley?

[annevk]

Also fix web-platform-tests/wpt#3610 (comment) as part of fixing the test. (Assuming everyone is okay with fixing the test.)

[domenic]

Right, I think the spec is correct-ish here, but again it's just the problem of confusing the behavior of Object.setPrototypeOf with the [[SetPrototypeOf]] internal method. Returning false from the latter translates to throwing a TypeError from the former. (And there is no strict/sloppy distinction here.)

I think what remains is to decide whether we want to throw a TypeError cross-origin, or a DOMException SecurityError. That question is probably the same for all internal methods (so #1726/#1728 need to align with whatever we decide).

We will always through a TypeError same-origin; as @bzbarsky points out that is somewhat of a recent change, but an important one for security.

[domenic]

Edge does not throw (but also fails the "Basic sanity-checking") when running http://w3c-test.org/html/browsers/origin/cross-origin-objects/cross-origin-objects.sub.html

[cdumez]

Well, all browsers will fail Basic Sanity-checking if the test is hosted on port 80:
assert_equals: Need to run the top-level test from port 80 expected "80" but got ""

This is the test that needs fixing.

[bholley]

I'll defer to @bzbarsky on the details of exactly what sort of exceptions are thrown.

Checking this in the test is good, but please make sure to do it in such a way that a browser that throws the wrong sort of exception still gets credit for throwing an exception, and merely fails an additional "right kind of exception" test.

[cdumez]

I am updating WebKit [1] to throw a TypeError in the cross-origin case as per:

• https://tc39.github.io/ecma262/#sec-object.setprototypeof (step 5)

For now, we still allow setting the prototype in the same origin case, similarly to Chrome.

[1] https://bugs.webkit.org/show_bug.cgi?id=161396

[annevk]

Given #1728 (comment) it seems this can be closed as "worksforme"? That is, since the behavior is supposed to be consistent for same-origin and cross-origin, we'll leave this as a TypeError?

[annevk]

I created a WPT PR to test for the specific exceptions. As requested I've done it as a separate resource for now so browsers can separately check whether they throw at all and whether they throw the correct exception. Once a couple of browsers start throwing the correct exceptions I suggest we only use that resource going forward. It's not worth the hassle to maintain it twice.

[cdumez]

Yes, the specification seems correct here.