Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 787013 - xraywrappers doesn't inherit from Object and are missing common methods
: xraywrappers doesn't inherit from Object and are missing common methods
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
Depends on:
  Show dependency treegraph
Reported: 2012-08-30 05:25 PDT by Alexandre Poirot [:ochameau]
Modified: 2014-10-01 06:22 PDT (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Alexandre Poirot [:ochameau] 2012-08-30 05:25:36 PDT
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),
Comment 1 Gabor Krizsanits [:krizsa :gabor] 2012-08-30 07:28:50 PDT
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] 2012-08-30 08:01:52 PDT
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);
Comment 3 Gabor Krizsanits [:krizsa :gabor] 2012-08-30 08:29:44 PDT
(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) (busy with Stylo) 2012-09-04 16:02:11 PDT
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 2014-10-01 06:22:00 PDT
resolved recently, see bug 1074885 for more info..

Note You need to log in before you can comment on or make changes to this bug.