On 3/14/2014 11:26 PM, Boris Zbarsky wrote:
For non-core, if you control the Gecko you build against, then the
answer is the same. If you have to work against a random Gecko,
that's a problem we don't have a good solution for yet.
Assuming you really need to expose the object to a web page. On the
other hand, it's not clear to me that you want to be exposing objects
to all web pages like that, in general.
Isn't this something which pagemod addons and greasemonkey already do?
There's clearly lots of use-cases for polyfills or experiments provided
by addons. Do we not have a safe way now to expose objects and functions
to pages (all pages or some pages)?
I did discover recently that you can expose properties on the global of
a Cu.Sandbox, but only the global, and you can't expose deep object
hierarchies. There are also scary warnings about using return results
from an .evalInSandbox on this doc page, which seem like footguns still:
https://developer.mozilla.org/en-US/docs/Components.utils.evalInSandbox
For my case, I wasn't calling into the DOM, I was calling into a
null-principal sandbox, but the sandbox was basically supposed to define
a function:
// Filter for whether to run a telemetry experiment
function filter(context) {
if ("inspec...@mozilla.org" in
context.healthReportPayload.data.last.org.mozilla.addons.addons) {
return false;
}
return true;
}
And then I would call the Sandbox.filter function with a context object
that has the FHR payload. But since you can't pass complex objects to a
sandbox, I've had to serialize the structure using JSON and deserialize
it in the sandbox. Maybe this means we should consider exposing some
kind of structured-clone system for calling untrusted code, plus a safer
way to call functions which may return arbitrary results?
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform