On Fri, Sep 20, 2013 at 6:06 AM, Benjamin Smedberg <benja...@smedbergs.us> wrote: > Currently, extensions are able to use the JSAPI via its exported symbols. > This pretty much invariably leads to stability or security issues with > extensions that actually do this: > > * the JSAPI is complicated, and even within Mozilla we get reviews from a > select set of people on JSAPI code > * the JSAPI is moving quickly for such features as exact rooting as well as > things like compartments and the interaction with xpconnect. Extensions > aren't keeping up. > * the JSAPI is not a binary-stable interface but some people are trying to > use it that way > > So I would like to propose that we link the JS libraries statically into > libxul and stop exporting JSAPI symbols entirely. This will effectively > prevent extensions from using it.
Yes please. Interacting with JSAPI without crashing now requires using nsCxPusher (among other things), and the idea of addons manipulating the JSContext stack gives me the creeps. > There are some technical issues to work out, such as what we do with > xpcshell. I think what I'd like to do is bake xpcshell directly into libxul. > As a side benefit this will aid a long-term goal of mine to unify the > startup paths across app/embedding/xpcshell launch. That would be great. Also, there's a bunch of gunk we have to NS_EXPORT_ in order to let xpcshell use it. Fixing this would remove some cruft from XPConnect. bholley _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
