914970 - (XrayToJS) Implement meaningful Xrays to non-reflector JS objects

Reporter

Description

•

11 years ago

This has becoming more and more of a problem, and I think we'll need to fix it at some point.

The basic problem is that our Xray machinery only works for reflectors (either XPCWN or new binding objects). This is problematic from a number of angles:

1 - |new contentWindow.DOMError()| works, but |new contentWindow.Error()| does not. More generally, we don't have any safe way to create instances of ES-defined objects in Xrayed scopes. In bug 629607, for example, the console API wants to create a proxy in the content scope, but can't do so safely without some Cu hackery. We currently have Cu.createObjectIn, and we may need to add Cu.createProxyIn. But these are all just crutches for our inability to do |new contentWindow.Object(...)| and |new contentWindow.Proxy(...)|.

2 - As more and more stuff starts getting implemented in ES, we start to seriously suffer from our inability to safely manipulate objects in Xrayed scopes. Typed Arrays are one such example, but there are others. Anne wants to move Promises into the JS engine, for example.

The traditional reasoning for the lack of Xrays in this situation is "well, what would you Xray _to_? It's just JS!" This is somewhat valid, but not really. Different JS objects (like Date) have plenty of protected state that lives in reserved slots, but that information isn't exposed outside of the engine.

Bill and I talked for about this for a while on monday. Our main observation was that, modulo certain JSClass hooks, most of the interface for different types of JS objects is encapsulated in JSNative-implemented functions that live on the prototype. We can most likely use this to our advantage. Here's what I think we should do:

1 - Add an API to spidermonkey to access the "natural" prototype of a standard object. This should be very straightforward to do, because of the JS_IdentifyClassPrototype machinery that I added last year. This machinery currently just detect whether the object in question is a bonafide prototype. But since the prototypes share a JSClass with instances, all we need to do is invert the filtering machinery in js_IdentifyClassPrototype so that we detect instances instead.

2 - Add an API to look up the bonafide JSNatives that should exist on the prototype, ignoring whatever mucking about the content script may have done with the prototype object itself. I have no idea how hard this is, but it's probably not trivial. Anyone have any thoughts on how to go about this?

3 - Implement Xray traits for identifiable standard objects that utilize the above APIs to determine the natural behavior of the object. We may need to do some special-casing for objects that rely on JSClass hooks (Arrays, what else?), but this should be doable if we solve (2).

Thoughts? I'd especially like to heard from Waldo/jorendorff/luke about (2).

Jason Orendorff [:jorendorff]

Comment 1

•

11 years ago

Re (2), suppose each prototype object had a pointer to the JSFunctionSpec/JSPropertySpec arrays. That wouldn't be hard. Or we could embed those pointers in the JSClass instead, which would be even safer.

We could support JS-language methods and accessors too. It would just take a little more work. We could have some kind of (per-compartment?) registry of the methods and accessors of JSClasses, and then you could make a JSClass xray-able just by adding the relevant information about it to the registry (which we would let you do from C++ or from self-hosted, or chrome, JS code).