WindowProxy and reification

[annevk]

I'd like to continue the discussion in tc39/ecma262#688 (comment) to make sure I'm not missing something.

In particular, assuming you can associate a private field X with a windowProxy instance and X can be reified somehow. If document A does this. And then the user navigates to document B. Can B get to windowProxy's X in some way?

Or would it be impossible because to associate the private field you need to create a subclass and the subclass will be eligible for GC by the time you get B?

cc @ljharb @erights

[ljharb]

Assuming each “navigation” is a fresh instance, then I’d assume that the instance’s X field’s value would be entirely different, just like if X is a string or a symbol. (I’m not super familiar with how window proxy works).

If it’s the same object, and document B has no way to get at X directly, then there shouldn’t be any way to determine it from the object (just like in document A where you have no direct access to X)

[annevk]

What do you mean by a navigation being a fresh instance? The windowProxy instance A and B see is the same.

[bakkot]

Private fields have pretty much exactly the same semantics as WeakMaps, so unless this is already a problem with putting a windowProxy into a WeakMap it should not be a problem here.

That argument aside: merely having access to an object does not give you any way of accessing the values of private fields on that object. Nor, with this or any other proposal I am aware of, would it give you access to the reified Private Name objects themselves (just as having access to an object which has been placed into a WeakMap does not give you access to the WeakMap).

So I think it ought to be OK unless there's some other way of carrying values over after navigation, which would imply this is already a problem for WeakMaps.

[annevk]

Thanks, that helps. Let's close this.

(FWIW, there are interop issues around this, but I agree that in principle there does not appear to be a problem: https://bugzilla.mozilla.org/show_bug.cgi?id=1652868#c3.)

[bakkot]

Speaking just as a delegate: if this is too much an issue, I strongly suspect the committee would be amenable to adding an opt-out mechanism which would let hosts declare a host object as being ineligible for having private fields added. Using the return override trick to stamp new fields on an existing object is already a bit strange, and doing it on a windowProxy in particular is extremely strange. So if browsers are needing to do a bunch of work to special case this scenario, it might be acceptable to tweak the language to rule out this extremely special case.

[erights]

The return override issue is extremely problematic already. Adding a special case exemption specific to hosts would only make things worse. Adding some more general opt-out mechanism may conceivably be good, but I cannot think of anything plausible. Altogether I am skeptical. Consistently broken is bad, but is better than inconsistently broken.

[erights]

From my comment at https://bugzilla.mozilla.org/show_bug.cgi?id=1652868#c6 :

Safari's behavior is correct. The others are incorrect. We need test262 tests demonstrating this.

[ljharb]

I agree a special exception seems bad (despite agreeing with the unlikelihood that someone would run into it).

I think it’s important that anything that can have a private field can also be a weak target, and it seems better for a general mechanism to exempt an object from those than for a host-specific one.

[bakkot]

Consistently broken is bad, but is better than inconsistently broken.

I wouldn't have suggested it if windowProxies were not already extremely special. But they are extremely special, and making them very slightly more so doesn't bother me.

[erights]

It does bother me. In fact, we need to make it less special to the extent possible. We need to reverse the browser decision to break the object invariants. Given that the proxy enforcement of these invariants is inductive --- it depends on no other potential target already violating these invariants --- this "intentional violation" is a disaster. We need test262 tests to demonstrate this violation and provide a concrete incentive to get all hosts to conform. Including browsers.