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

Status: RESOLVED WORKSFORME

(Core :: XPConnect, defect)

Description

[Alexandre Poirot [:ochameau]]

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.

http://mxr.mozilla.org/mozilla-central/source/js/src/jsobj.cpp#2260
JSFunctionSpec object_methods[] = {
#if JS_HAS_TOSOURCE
    JS_FN(js_toSource_str,             obj_toSource,                0,0),
#endif
    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),
#if JS_HAS_OBJ_WATCHPOINT
    JS_FN(js_watch_str,                obj_watch,                   2,0),
    JS_FN(js_unwatch_str,              obj_unwatch,                 1,0),
#endif
    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),
#if OLD_GETTER_SETTER_METHODS
    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),
#endif
    JS_FS_END
};

Comment 1

[Gabor Krizsanits (INACTIVE)]

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...

Comment 2

[Alexandre Poirot [:ochameau]]

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() {
    String.prototype.foo = "bar";
    return window.document.body.innerHTML.foo;
  } + ")()", sb);
  Components.utils.reportError(rv);

Comment 3

[Gabor Krizsanits (INACTIVE)]

(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.

Comment 4

[Bobby Holley (:bholley)]

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?

Comment 5

[Tomislav Jovanovic :zombie]

resolved recently, see bug 1074885 for more info..