Detecting slow add-ons

As we have been progressing towards a multi-process Firefox we have seen many bugs filed about slowness that after investigation turned out to be related to add-ons interacting poorly with the way multi-process Firefox now operates. This doesn’t necessarily mean that the add-on author has done anything wrong. Instead code that worked fine with single-process Firefox now behaves differently as seemingly innocuous calls can cause synchronous calls from one process to the other. See my previous post on unsafe CPOW usage as example of how this can occur.

This motivated us to start trying to measure add-ons and detect when they may be slowing down a user’s browser such that we can notify the user. As luck would have it, we recently made a key change that makes all of this possible. In bug 990729 we introduced “compartment-per-add-on” (though there may be multiple compartments per add-on), such that add-on code and Firefox’s js code run in separate compartments. This allowed us to then track the amount of time we running a particular add-on by measuring the time spent in the compartments associated with that add-on. We did that in bug 1096666.

That has allowed us to start notifying users when we notice add-ons running slowly on their system. The first cut of that recently landed from bug 1071880, but a more polished UX is being tracked by bug 1124073. If you’re using Nightly and testing e10s (multi-process Firefox) and are notified of a slow add-on, please try disabling it to see if it improves how Firefox is running and report your results to AreWeE10SYet.com. You can see the raw data of what we are measuring by having a look at about:compartments. Also note that all of this is experimental. In fact, we’re already rewriting how we measure the time we spend in compartments in bug 674779.