OrdinarySetPrototypeOf and the HTML spec

[saambarati]

Currently, OrdinarySetPrototypeOf bails from its cycle checking loop early if it sees a [[GetPrototypeOf]] which isn't the default implementation. I'm guessing this is in awareness of the Proxy's [[GetPrototypeOf]]. Is that correct? If not, what is the reasoning behind this decision?
I'm looking at: https://tc39.github.io/ecma262/#sec-ordinarysetprototypeof

The HTML spec overrides [[GetPrototypeOf]] on the window proxy. Calling [[SetPrototypeOf]] on an object who's [[Prototype]] is WindowProxy can lead to cycles now.
I'm looking at: https://html.spec.whatwg.org/#windowproxy-getprototypeof

Like so:

let o = {__proto__: window};
window.__proto__.__proto__.__proto__.__proto__ = o

(I believe this throws cycle exceptions in browsers, however, it should not according to the spec, if I'm reading it correctly, and have constructed my example correctly.)

I believe that if we don't consider the browser, it's impossible to get a cycle if you directly loop over the [[Prototype]] property. However, with the HTML spec, I believe that's no longer true.

I wonder if the function can be more restrictive, and only bail out on the loop if we encounter a ProxyObject.[[GetPrototypeOf]] internal method, instead of bailing once we see the non-default [[GetPrototypeOf]].

What are people's thoughts? I'm mostly posting here to bring awareness to this issue and to understand previous discussions of it, or to have new discussions about it. We're currently running into issues with this property inside WebKit.

[domenic]

I think @jswalden also ran into this, judging by https://blog.whatwg.org/windowproxy-window-and-location#comments ...

(I have not taken the time to form an opinion on this. In general I think anything that is web-compatible is probably fine in these kind of edge cases?)

[littledan]

Cc @verwaest

[allenwb]

see https://bugs.ecmascript.org/show_bug.cgi?id=2437 for the background of this semantics

It seems perfectly reasonable for the HTML spec to provide modifications to steps of 8.c.i-ii of OrdinarySetPrototypeOf that take the WindowProxy object into account

[bterlson]

The rationale wasn't entirely proxy-based - generally, exotic objects can have a [[GetPrototypeOf]] implementation that can do arbitrary things and it's impossible to enforce that there are no observable circularities. Proxies are an obvious case where this can happen however.

That said, it totally makes sense that an embedding would want exotic objects with overridden [[GetPrototypeOf]] slots to nonetheless behave as if [[GetPrototypeOf]] were ordinary for the purposes of circularity checks. I can't think of a clean way to expose this through 262's layering API however. Another alternative is for HTML to ammend OrdinarySetPrototypeOf Step 8.c.i to state something like "If the [[GetPrototypeOf]] internal method of p is not the ordinary object internal method defined in 9.1.1 and not WindowProxy's [[GetPrototypeOf]] internal method, let done be true." Since this is so edge-casey I don't think this is too bad.

[domenic]

I still haven't taken the time to understand this issue in full, so I'm just assuming that you guys are right that this is the best solution :). But I would really prefer not to have that kind of monkeypatch and willful violation. Instead could we define something like a "non-circular exotic [[GetPrototypeOf]] internal method", change ES to have "is not the ordinary object internal method defined in 9.1.1 and is not a non-circular exotic [[GetPrototypeOf]] internal method", and then say in HTML that the [[GetPrototypeOf]] for WindowProxy and Location are non-circular exotic [[GetPrototypeOf]] internal methods?

[bterlson]

@domenic that would work too, but it's a lot of verbage to support this edge case. We also don't have a notion of special "kinds" for internal methods in the spec and I'd not like to add it just for this. It's a lot of conceptual overhead.

[domenic]

Then could we add a reference directly to WindowProxy's [[GetPrototypeOf]] to the ES spec?

[allenwb]

@domenic

Then could we add a reference directly to WindowProxy's [[GetPrototypeOf]] to the ES spec?

That would give special status to HTML. Whose to say that some other host environment spec. might not want to do something similar. It seems cleaner to me, to leave to such host environment specification to say what they require (and to negotiate with engines to support it).

[domenic]

Yes, that's exactly the negotation we're performing here :). I'd just like to get it written into the spec. As you say, other host environments might have the same requirement, so it'd be good if the spec had a mechanism for doing so.

[cdumez]

FYI, this is not just HTML's WindowProxy that is affected but also HTML's Location object.

[domenic]

We also don't have a notion of special "kinds" for internal methods in the spec and I'd not like to add it just for this.

We could also define a special kind of exotic object (the precedent being immutable prototype exotic objects) and test if p is one of those. E.g. a "circular-prototype-checked exotic object"

[allenwb]

I'd just like to get it written into the spec. As you say, other host environments might have the same requirement, so it'd be good if the spec had a mechanism for doing so.

My point was more that other environments might have different requirements or requirements relating to other parts of the ES spec. Trying to accommodate such implementation specific requirements adds spec. complexity that impacts everybody. (arguably, this current issue relates to existing complexity that was added as an implementor accommodation). In addition, such accommodations can be seen as sanctioning such extensions, when we might prefer to discourage them.

Finally, look at it from an architectural layering perspective. Many environments can be layered on top of ES. Architecturally "down links" rather than "up links" are preferable and more maintainable.

[domenic]

I just don't think it's reasonable to say that for something as basic as OrdinaryGetPrototypeOf, web browsers cannot look at the ES spec, and must instead implement the HTML spec's version. If we set that kind of precedent, then the ES spec becomes entirely unreliable as a guide to what implementations should implement and the behaviors and invariants developers can assume. @erights has commented on this in the past in other issues.

Instead, I'd like to use the tried-and-true practice of decoupling dependencies via agnostic, targeted hooks of the sort described.

If we want to be even more generic, to accomodate those varying options you describe, then I guess the canonical path is to create a HostOrdinarySetPrototypeOfSteps(O, V) operation, and insert it after step 8 of OrdinarySetPrototypeOf. That seems like over-engineering to me compared to adding a special kind of exotic object, or similar. But if that's what the editor would prefer I'm happy to do that too.

[bterlson]

IIUC circular-prototype-checked exotic object isn't right - the ability to depend on GetPrototypeOf for circularity checks is orthogonal to the exoticness of an object. In other words, a named exotic object is just an object with a specific set of non-standard slots so a circular-prototype-checked exotic object wouldn't work because it actually describes a constraint on the behavior of [[GetPrototypeOf]] rather than a particular slot value.

Another option would be a slot flag for ordinary objects, something like [[GetPrototypeOfReliableForCircularityChecks]]. Its value is true for ordinary objects and false for proxy objects. Problem I see with this design is that it assumes that objects that override [[GetPrototypeOf]] are reliable when probably assuming the opposite is safest.

I still feel that any option is a lot of machinery for an edge case with a pretty tiny spec patch :-P It makes 262 harder to understand and doesn't help HTML all that much.