Closed Bug 787013 Opened 12 years ago Closed 10 years ago

xraywrappers doesn't inherit from Object and are missing common methods


(Core :: XPConnect, defect)

Not set





(Reporter: ochameau, Unassigned)


xraywrappers are lacking a set of JS methods. The ones from global `Object` object.
Like toLocaleString, valueOf, toSource, watch and so on.

We are using xraywrappers in jetpack for content scripts and we are trying to provide to addon developers an environnement where object behave almost exactly like regular webpage objects.
So that the miss of this method is negative even if it isn't highly critical. We are afraid that some commonly used JS framework depends on such method.
JSFunctionSpec object_methods[] = {
    JS_FN(js_toSource_str,             obj_toSource,                0,0),
    JS_FN(js_toString_str,             obj_toString,                0,0),
    JS_FN(js_toLocaleString_str,       obj_toLocaleString,          0,0),
    JS_FN(js_valueOf_str,              obj_valueOf,                 0,0),
    JS_FN(js_watch_str,                obj_watch,                   2,0),
    JS_FN(js_unwatch_str,              obj_unwatch,                 1,0),
    JS_FN(js_hasOwnProperty_str,       obj_hasOwnProperty,          1,0),
    JS_FN(js_isPrototypeOf_str,        obj_isPrototypeOf,           1,0),
    JS_FN(js_propertyIsEnumerable_str, obj_propertyIsEnumerable,    1,0),
    JS_FN(js_defineGetter_str,         js::obj_defineGetter,        2,0),
    JS_FN(js_defineSetter_str,         js::obj_defineSetter,        2,0),
    JS_FN(js_lookupGetter_str,         obj_lookupGetter,            1,0),
    JS_FN(js_lookupSetter_str,         obj_lookupSetter,            1,0),
There is an obvious reason why the Object of the content compartment is not in the prototype chain of the xray wrapper, but like for toString we could implemented these methods on the wrapper probably. Even for defineGetter/Setter we could implement something that effects only expando creation and has no effect on the content side. Probably it's quite some work...
TBH, I'd think that we should inherit objects from xray's globals.

With a pattern similar to what we do we strings. Strings that comes from xraywrapper's string attributes are inheriting from xray compartment global String object.

Here is a proof of concept:
  var sb = Components.utils.Sandbox(content);
  sb.window = content;
  var rv = Components.utils.evalInSandbox("(" + function SandboxContext() { = "bar";
  } + ")()", sb);
(In reply to Alexandre Poirot (:ochameau) from comment #2)
> TBH, I'd think that we should inherit objects from xray's globals.

I don't think the original implementation of these methods what we really need here, I would be surprised if they worked nicely together with expandos of xrays.
The issue here is that Xray wrappers are JS proxies, which means that their prototype chains aren't meaningful. When a property lookup happens, we land in XrayWrapper::getPropertyDescriptor, and that's it - there's no bouncing up the prototype chain.

If the call to Traits::resolveNativeProperty (in XrayWrapper::getPropertyDescriptor) doesn't come up with anything, we could do an explicit lookup on Object.prototype. That's a little gross, but I think it'd fix the problem here without introducing any of the threat surface that comes along with examining the wrapped object's prototype chain.

Gabor, what do you think?
resolved recently, see bug 1074885 for more info..
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.