Hi everyone, Brian Hackett, Bobby Holley, and I have been working on some changes to the way that add-ons run (bug 990729). These changes make possible a lot of awesome new features for monitoring add-on performance and memory usage (which I'll talk about below). However, there's the possibility that some add-ons might break. The changes have landed on nightly but they're hidden behind a pref. Before we can enable them, I'd like to ask people to enable the pref locally and do some simple testing. Here's what you need to do if you'd like to help out:
1. Get the latest nightly. 2. Go to about:config and set the dom.compartment_per_addon preference (you should see it set to false by default). 3. Do whatever you normally do. 4. If you notice any abnormal behavior with your add-ons, file a bug under XPConnect, CC me (:billm), block bug 1030420, and include details about the add-on and what's going wrong. If something goes wrong, it will probably be related to global variables attached to the window that can't be found. However, these errors could manifest in all sorts of ways, so please look for anything strange. WHAT IS THE CHANGE? We're trying to isolate add-on code so that it doesn't run in the same compartments as normal Firefox code. For add-on code in JSMs and components, we already do that. Bug 990729 makes it so that code attached to XUL overlays (<script> elements and inline event handlers) runs in a different compartment from the Firefox window. Bug 1017310 additionally makes it so that chrome XBL code runs in a separate compartment as well. There are still some holes in the scheme, though. Content XBL code isn't separated out. Flashblock is the only add-on we know of that uses content XBL, so we're still deciding whether that's worth fixing. WHAT ARE THE BENEFITS? Right now there aren't any. However, a lot of cool things should be possible with these patches: * Previously, a lot of add-on memory usage was mixed in with chrome code. With this change, about:memory will be able to completely separate out memory allocated by add-ons from memory allocated by Firefox. Eventually, it should also be possible to track how much memory is kept alive by add-ons--that is, memory that would be released if an add-on weren't holding on to it. * Every time we start running code for an add-on, we'll have to go through cross-compartment wrappers. With the right wrappers, we'll be able to track how much time we spend running add-on code. This information could be really useful for the profiler or for telemetry. * We'll be able to track which APIs are used by add-ons. Searching mxr.m.o/addons is really useful if you're considering deprecating an API, but it doesn't tell you anything about non-AMO add-ons. With this change, we'll be to instrument the browser to report which add-ons are calling a given API and to report that information via telemetry or something. * We'll be able to expose a different API surface to add-ons than we do to the rest of the browser. So we'll be able to deprecate an API in Firefox but still offer it to add-ons. We'll also be able to hide certain APIs from add-ons. * We're going to use this stuff for electrolysis to intercept any add-on calls that might touch content objects so that we can take an alternate path. The hope is that we'll be able to make a lot more add-ons compatible with e10s. This is the original motivation for the bug. Only the electrolysis stuff is being actively worked on right now. If any of this other stuff sounds interesting and you'd like to work on it, please contact me! HOW DOES THIS AFFECT MEMORY USAGE? Even though they sound similar, this change shouldn't have anywhere near the effect on memory that compartment-per-global did. Most users have only one Firefox window open and only a few add-ons installed so we'll only be creating an extra 3 or 4 compartments. A typical Firefox user already has ~500 compartments, so this change won't affect the total much. -Bill _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
