Mozilla began an aggressive campaign earlier this year to trim Firefox’s memory footprint with a new initiative called MemShrink. The first fruits of that effort landed in Firefox 7, which was released in September. As a result, Firefox’s memory consumption is now between 20 to 50 percent lower. Building on that success, Mozilla is expanding the scope of its MemShrink initiative and looking to address memory consumption in additional areas.

In a blog post published earlier this week, Mozilla’s Justin Lebar proposed a strategy for tackling memory leaks in third-party add-ons — a common source of Firefox memory problems. Firefox’s add-on ecosystem is one of the browser’s great strengths, but it also presents challenges.

Add-ons can behave in unpredictable ways — it’s not always clear to users when a problem they encounter in Firefox is caused by the browser or by third-party code. As Lebar says, the time has come for Mozilla to start taking a more active role in protecting users from add-on misbehavior. Mozilla already loosely polices its add-on site to protect users from malware, so taking proactive steps to flag leaky add-ons seems like a logical step.

“The fact is, if we take credit for our vibrant add-on community, we must take responsibility for the problems those add-ons cause,” Lebar wrote. “This shouldn’t be controversial; we already check to ensure that add-ons aren’t outright malicious before posting them to AMO, acknowledging that the buck stops at Mozilla when there’s a misbehaving add-on. Even if it’s not our bug, it’s in our software, and people will blame us, not their add-ons.”

Lebar’s proposed strategy includes three approaches, which he calls the carrot, the stick, and the wrench. The carrot approach will involve changing Mozilla’s add-on website so that testing for “zombie compartments” that leak memory is a standard part of the process for submitting a new add-on.

The stick approach will involve flagging and publicly identifying add-ons that leak a lot of memory-much like a previous experiment in which slow add-ons were named and shamed. Finally, the wrench approach will involve building better tools that will make it easier for add-on developers to identify and resolve memory leaks themselves.

Lebar suggests using all three approaches together. Tickets have been opened in Mozilla’s bug tracker to facilitate developer discussion about the proposal and how to proceed with an implementation. Users can hopefully expect to see a meaningful improvement in add-on memory overhead when the plan goes into effect.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

See Also: