This is a kind of object that often crosses privilege boundaries. For example, in bug 987222, exceptions that propagate into XBL end up looking like this: System JS : ERROR (null):0 - uncaught exception: [Opaque] We should implement useful Xrays here, which will at least make the [Opaque] say something more useful.

I don't think we should be exposing info about an exception to a scope that couldn't normally read that info....

(In reply to Boris Zbarsky [:bz] from comment #1) > I don't think we should be exposing info about an exception to a scope that > couldn't normally read that info.... Oh, for sure. The filtering policy will take care of that. The issue here is with the inverse wrapper, whereby we protect privileged code from less-privileged code by making the wrappers opaque (we do this for XBL scopes, where we don't have the compatibility burden we have in the general case). The issue in bug 987222 is that the page throws an exception, but it gets reported in the XBL scope, where stringifying it gives "[Opaque]". Xrays will fix that for us.

Comment on attachment 8453287 [details] [diff] [review] Part 3 - Implement Xray support for the data properties on ErrorObject instances. v1 Review of attachment 8453287 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/xpconnect/wrappers/XrayWrapper.cpp @@ +621,5 @@ > + if (isErrorIntProperty || isErrorStringProperty) { > + RootedObject waiver(cx, wrapper); > + if (!WrapperFactory::WaiveXrayAndWrap(cx, &waiver)) > + return false; > + if (!JS_GetOwnPropertyDescriptorById(cx, waiver, id, desc)) This might be a stupid question, but is there a way that the underlying object has a proxy in its proto chain that can interrupt this? Normally that would not be an issue but after the waiving it... r=me with either adding an isJSProxy call here, or explaining me why this cannot be an issue and/or adding a test for it.

(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #10) > > + if (isErrorIntProperty || isErrorStringProperty) { > > + RootedObject waiver(cx, wrapper); > > + if (!WrapperFactory::WaiveXrayAndWrap(cx, &waiver)) > > + return false; > > + if (!JS_GetOwnPropertyDescriptorById(cx, waiver, id, desc)) > > This might be a stupid question, but is there a way that the underlying > object has a proxy in its proto chain that can interrupt this? Normally that > would not be an issue but after the waiving it... r=me with either adding an > isJSProxy call here, or explaining me why this cannot be an issue and/or > adding a test for it. It's a non-issue because we know the JSClass of target is ErrorObject::class_, and the lookup is |own|, which means we never hit the proto.

Ah right, I forgot about the own part! Nevermind then.

Thanks for the reviews gabor! remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/2f058f0f4c1c remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/8fed72d0f496 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/4e45b8a55bfb remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/e171c0317b82 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/a2cbaa337120 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/48b4e65d344d

Followup bustage fix: https://hg.mozilla.org/integration/mozilla-inbound/rev/d257e3805fc7

https://hg.mozilla.org/mozilla-central/rev/2f058f0f4c1c https://hg.mozilla.org/mozilla-central/rev/8fed72d0f496 https://hg.mozilla.org/mozilla-central/rev/4e45b8a55bfb https://hg.mozilla.org/mozilla-central/rev/e171c0317b82 https://hg.mozilla.org/mozilla-central/rev/a2cbaa337120 https://hg.mozilla.org/mozilla-central/rev/48b4e65d344d https://hg.mozilla.org/mozilla-central/rev/d257e3805fc7