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

RESOLVED WORKSFORME

Status

()

Core
XPConnect
RESOLVED WORKSFORME
5 years ago
3 years ago

People

(Reporter: ochameau, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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
};
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...
(Reporter)

Comment 2

5 years ago
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);
(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..
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.