1717710 - Private Fields inadvertently tunnel through to the Window object, rather than being stored on WindowProxy as expected

Status: RESOLVED DUPLICATE of bug 1726039

(Core :: JavaScript Engine, task, P1)

Description

[Matthew Gaudet (he/him) [:mgaudet]]

While investigating Bug 1652868 I discovered that our implementation of Private Fields were stamping fields onto the target object, as WindowProxy is a transparent proxy type, rather than storing the fields on the proxy as one would expect from the weak map.

Comment 1

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: Bug 1717710 - Make sure private fields and methods are stored on the proxy, not the Window object. r?nika

Note: While having this patch is strictly better than not having this patch,
it's still not 100% compliant with the standard. I would be interested in if
it was possible to draw the distinction between the Window and the WindowProxy
in ways that don't trigger some of the other problems with WindowProxy and
private fields...

Comment 2

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: Bug 1717710 - WPT Test for private fields and their carried status for WindowProxies and Location objects. r?peterv

Comment 3

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: Bug 1717710 - Support Private Fields on WindowProxies correctly. r?peterv!,jandem!

To recap briefly for those who weren't involved: Private Fields are actually
modelled as hidden properties on objects; this works out fairly well right up
until one encounters proxies. At that point, one is forced to acknowledge that
the specification of Private Fields is thought in terms of a 'hidden WeakMap',
associated with a class, where the key is the object that 'has' a given private
field.

This means that if you stamp a private field on a Proxy, it does -not- tunnel
through to the target object. The problem is, Firefox is riddled with transparent
proxies, for example CCWs, where you want the private field to land on the target,
not the proxy.

To handle this, the Proxy implementation was made configurable. Classes which need
transparent behaviour return false from useProxyExpandoObjectForPrivateFields, and
classes which desire private fields to end up on the proxy itself, return true.

WindowProxies are special however. These objects are transplanted during
navigation, and so as a result we need to ensure that JS_TransplantObject does
the right thing for transplanting a proxy with an expando.

Comment 4

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: WIP: Bug 1717710 - Teach nsGlobalOuterWindow and MaybeCrossOriginObject how to use the ProxyExpando object

Comment 5

[Matthew Gaudet (he/him) [:mgaudet]]

A status update here: D118414 has a semi-functional version of this working, however, it turns out to be incorrect -- it ends up not handling the peculiar compartment oddities around transplanted window proxies.

D141519 may be better. It takes a totally different approach of teaching nsOuterWindowProxy about the private field expando. Unfortunately, it's likely insufficient in the face of RemoteOuterWindowProxies (i've yet to write the test case, but I would likely have to write something similar to dom/tests/browser/browser_windowProxy_transplant.js)

At this point, I'm annoyed. I actually think we should do Bug 1726039, which would make cross origin objects ineligible for private fields, and sidestep this whole problem; I would follow that up with work to specify this.

Comment 6

[Matthew Gaudet (he/him) [:mgaudet]]

Will be fixed via Bug 1726039