In the Memshrink and Snappy work we've found that a primary source of problems are buggy extensions. Ones that leave zombie compartments, which hold onto stuff causing long CC times, etc. For added fun, many of them are no longer maintained or the author is unable or unwilling to attempt to fix it. Two mechanisms are possible ways to deal with this. One we've discussed with the extension people - flagging extensions in a.m.o as being known leaky/bad/whatever (after some grace period for the dev to fix it). The other is this bug: find a way to flag to users at some point that extensions they have are known problematic. It's rather like blocklists and the upgrade-time flag of non-user-installed addons. We'd flag to the user that TorButton is known to leak memory and hurt performance, for example. (and in this case, TorButton is both unmaintained and not installed via AMO). Extensions are both a wonderful thing for FF and a bane of our existence when they're buggy or broken, and users tend to accumulate old/buggy/dead extensions, and never remove them (unless they become incompatible, and with recent changes that might not tend to happen). If we can leverage the mechanisms used to implement blocklists and non-user-installed warnings, it might not be a ton of effort. Probably need to CC a number of people from addons, etc

Just to clarify, the advantages of doing this in-browser instead of via AMO are that: (a) it would work for non-AMO add-ons, which is the majority of them; (b) it would let users know about problems in add-ons that are already installed, not just in add-ons that they update or install for the first time. These two factors would give dramatically more coverage than just some flags on AMO. Three examples came up in today's MemShrink meeting: - Customize Your Web. Bug 719782. It's on AMO but is no longer maintained, so existing users have no way of knowing it causes problems. - 1Password. Bug 719601. It's not on AMO, so users have no way of knowing it causes problems. - TorButton (which jesup mentioned). Bug 719329. Not only is it not on AMO, in order to not have to keep up with Firefox rapid releases they now release their own custom version of Firefox that has TorButton baked in. This is about the worst possible case for us; if we added a mechanism they could disable it in their custom versions. Definitely an unusual case.

Not that I don't think this is a good idea, but here are some reasons we might not want to do this: * Unless we're going to send to the browser the whole (long?) list of bad add-ons, the browser will need to tell Mozilla which add-ons it's running. This may be a privacy concern. * Shouldn't users be informed *before* they download a known-bad add-on as well? It seems that if we agree we should warn users who happen to look at about:addons, we should first put up warnings on AMO. That'll catch the vast majority of add-on downloads.

> * Shouldn't users be informed *before* they download a known-bad add-on as > well? It seems that if we agree we should warn users who happen to look at > about:addons, we should first put up warnings on AMO. That'll catch the > vast majority of add-on downloads. That's bug 695481, and it would be great to have as well. But, IIRC, the majority of installed add-ons are *not* hosted on AMO.

> But, IIRC, the majority of installed add-ons are *not* hosted on AMO. orly? Is that because they're installed by third-party apps?

I can think of multiple ways to deal with the bandwidth / size issue: compression; report list version and be sent a delta, etc. I'd assert that's a solvable issue. The other assertion I'd make is that the number of buggy existing installs vastly outnumbers new downloads of buggy addons.

> I'd assert [the size of the blacklist is] a solvable issue. I agree. > The other assertion I'd make is that the number of buggy existing installs vastly outnumbers new > downloads of buggy addons. But that's because we don't currently warn before people download the add-on, right? We all agree that what's suggested here is a much more difficult, much higher-profile, much higher-risk, much more difficult to get approved change than warning on AMO, right? All I'm saying is, we should do AMO first and learn from that experience before we start to make major changes to the Firefox UI.

I think additionally, it makes little sense to flag in Firefox but not on AMO. That is, people will be surprised that we tell them that they have a bad add-on only after they download it. On the other hand, nobody will be surprised if AMO has metadata that's not in Firefox. Indeed, AMO already has lots of metadata, such as the add-on's rating, the number of times it's been downloaded, and comments. So again, I think we should focus on AMO as a prerequisite for this bug.

No disagreement - AMO changes should be the first focus, but largely those are different resources (and likely doable more quickly as well, especially into non-beta user hands - we have a fairly long delay even with release trains compared to AMO changes). I wouldn't hold off on working on this until the AMO changes are live.

At the moment, we haven't even gotten buy-in from the AMO team. I think that should be our first priority, given that we can only concentrate on so many things at once.

> I think additionally, it makes little sense to flag in Firefox but not on > AMO. fligtar or Asa needs to step in here with some numbers about how many non-AMO add-ons are in use...

We agree that the set [add-ons installed via AMO] union [add-ons installed by third-party (i.e., not by user)] is the vast majority of add-on installations, right? That is, of first-party add-on installations, via-AMO installations make up the vast majority? If so, I don't understand why the number (or proportion) of non-AMO add-ons in use matters, since these are attributable to third-parties and not something we can warn about in the first place.

(In reply to Justin Lebar [:jlebar] from comment #11) > We agree that the set > > [add-ons installed via AMO] union [add-ons installed by third-party (i.e., > not by user)] > > is the vast majority of add-on installations, right? That is, of > first-party add-on installations, via-AMO installations make up the vast > majority? > > If so, I don't understand why the number (or proportion) of non-AMO add-ons > in use matters, since these are attributable to third-parties and not > something we can warn about in the first place. We do warn about add-ons installed by third parties. We shipped that feature in Firefox 8.

Right. And what this bug is about is warning at *time to be decided* the user about known problematic addons they have - whether installed by AMO or not. I have addons I installed because they sounded interesting, and then they've sat there for years without being touched/used. Given the *long* lists of addons we often see in memshrink work, this isn't unusual. For added fun, modulo us happening to disable them due to version bumps (which may largely be going away for the future), as time goes by these become ever more likely to cause a problem. People will install Firefox N, notice that memory use has gone to hell (because of a bug in an crufty addon now exposed), and dump us for Chrome or IE. Or it's just part of how the browser seems to them to run slower with every release (as they accumulate leaky/broken addons or addons fall into unmaintained mode). It's a bit like how WinXP (or Vista, or 7) gets slower constantly as it accumulates cruft. ;-)

This is a real issue and one we must address sooner rather than later. I believe we should be addressing it on both sides -- at AMO and at Firefox, and that we can use the same mechanism to do so. I've updated our next in line "put users in control of their add-ons experience" feature page with my proposal for what this could look like. You can read all about that here: https://wiki.mozilla.org/Firefox/Features/Expose_Add-on_Performance#2._Users_.26_use_cases I believe that this proposal represents the requests made in Comment 0 of this bug and potentially a bunch of progress on bug 695481. I will secure Firefox client developer resources for this feature where I have some input into resourcing. If this plan is deemed appropriate, I will work with Justin to secure AMO side resources as well and we can nail this problem. We can't keep going back and forth on this while our users suffer. We must act now. I understand that defining "bad add-ons" will be contentious but so long as the technical approach is righteous we can sort out how heavy handed we want to be on policy at a later time and move forward implementing this today. In case folks aren't aware, and in the hope that it motivates some coming together here to make meaningful progress, the #1 reason Firefox users leave Firefox for Chrome is performance. I do not put all of the blame for performance problems on add-ons but I don't think anyone in this discussion disputes that it is a very real part of the problem. The sooner we agree on a plan, the sooner our users will get the relief they deserve.

Thanks, Asa. I'm not sure what's the right forum for comments on feature pages, but my only feedback is: It should be part of the plan to inform and involve the add-ons community as much as we can, even in the planning stages of this feature. This is a much larger change than the startup-time wall of shame, and that was pretty controversial (and could have benefited from add-on authors' input).

Is this a dup of bug 597282? It's certainly very similar. I guess one question is whether displaying this info in the add-ons manager is enough, or if we should be more aggressive, e.g. presenting pop-ups. https://wiki.mozilla.org/Firefox/Features/Expose_Add-on_Performance has a todo item "2. File AMO bug to make use of the new fields and display warnings when appropriate". Bug 695481 could be used for this purpose.

Good note about bug 597282. It's not a pure dup, but that's a blocker (and covers a good part of implementation here - great! Less new work to do!) Sounds like someone needs to re-energize that bug and make sure what that bug lands will smoothly lead into this work (or roll it into this work's release planning). And thanks for the strong support, Asa -- I've come to believe addons are a huge part of the pie of user dis-satisfaction with Firefox. (And a huge part of why they love it.)

(In reply to Randell Jesup [:jesup] from comment #17) > Good note about bug 597282. It's not a pure dup, but that's a blocker (and > covers a good part of implementation here - great! Less new work to do!) > Sounds like someone needs to re-energize that bug and make sure what that > bug lands will smoothly lead into this work (or roll it into this work's > release planning). The contributor that was working on bug 597282 has been too busy to commit any time to it for awhile. It's on my to-do list to finish it myself... but so are a million other things. I'm also planning on implementing those performance warnings into the new install experience (bug 643020). They should also go into the existing 3rd party install experience, though not sure off-hand if there's a bug on that. But both of those things are dependent on bug 597282.

(In reply to Randell Jesup [:jesup] from comment #17) > Good note about bug 597282. It's not a pure dup, but that's a blocker Can you explain why? I still can't see much difference between the two. The only real difference is the question of what form the data takes and how it's being pulled... looks like bug 597282 was filed with the automated start-up performance data in mind, but that is no longer being collected, AIUI. We're talking in this bug about pulling data from a manually curated list of bad add-ons.

Just throwing this out there: what will happen if someone has an extension that, as a byproduct of the way it operates, will always chew up a lot of memory & slow down page load times? What if it is impossible to achieve reasonable performance with the features of that add-on, then what? An example would be an add-on that takes a website, runs it through Google Translate & back a few times to produce some "Engrish", performs some text parsing to insert some images with JavaScript & CSS selectors, then renders the page as an old-fashioned, animated, 3D book in WebGL. There is no way to do all this snappily or slim-ly. While this may be a mostly "pointless" example add-on, there's bound to be some useful add-ons in this same situation. We need to decide how to treat the add-ons that will have a permanent red flag that's not due to any fault of the developer. As a straw-man I propose a way for an add-on developer to voluntarily indicate that their add-on causes performance issues. Something that informs the user without implying any "wall of shame" to the developer or an inherent problem with the add-on.

This is a good point, but it doesn't worry me too much. First of all, I'm particularly concerned about memory leaks resulting from poorly-written add-on code. If an add-on uses memory intentionally, I'm not inclined to flag it. Second, we're not going to put any add-on on the wall of shame without first trying to contact the author. I definitely don't want to repeat the fiasco with the "slow startup wall of shame", where a lot of authors (reasonably!) felt blindsided by the opaque process. So authors will get a chance to explain to us why they can't improve to the standards we ask. > As a straw-man I propose a way for an add-on developer to voluntarily indicate that their add-on > causes performance issues. Something that informs the user without implying any "wall of shame" to > the developer or an inherent problem with the add-on. You mean in addition to the involuntary flagging proposed here? I don't feel that we need to do anything to support this voluntary tagging. It's going to apply to a tiny fraction of add-ons. And the author already gets to write an add-on description, where she can add whatever performance caveats she wishes.

Firebug's a good example. It slows Firefox down because (a) it does a lot of useful stuff, *and* (b) it has some leaks. I think the right thing is to have multiple flags and careful descriptions, e.g.: - "This add-on is known to leak memory, which can cause Firefox to run more slowly than normal" - "The functions of this add-on can cause Firefox to run more slowly than normal" Firebug in its current form would get both of these. And having links to extra information will be very helpful, e.g. to bug reports for leaks.

> > But, IIRC, the majority of installed add-ons are *not* hosted on AMO. > > orly? Is that because they're installed by third-party apps? http://blog.fligtar.com/2011/09/26/add-on-compatibility-progress-plans/ says that "only 25% of the 600 million add-ons in use every day in Firefox 4 and later are active on AMO. That means at least 75% of add-ons aren’t getting ... the security and quality reviews that hosted add-ons receive."

That should say "add-on installations". That 75% (which should be lower after 8 was released) is covered by a few dozen non-hosted add-ons.

As a Fx user, what I'd like to see is a warning about any addon (whether AMO or not) that a) is badly coded, as in causing memory leaks, *unnecessarily* slowing down the browser (memory & computation), adding *unnecessary* clutter (~ Nagware not in the "traditional" sense), etc., b) is intentionally slowing down the browser (i. e. leak-free Firebug) and similar. The notification should be displayed 1) inside the addon manager, similar to the addon-not-compatible-warnings (e. g. orange text + warning singn for (a), blue text + info sign for (b) ), 2) for (a), in a popup (similar to the Fx update reminder) at time TBD (e. g. on Fx major version bump, and before addon install or after addon install if checking against blacklist is not possible before install) with the options to search for updates, disable or uninstall the addon, or dismiss the warning (remember ignoring e. g. until next Fx major version bump [c1]). The blacklist should be (delta-)downloaded (e. g. daily) and contain identifiers for problematic addons, including the last affected version and flags indicating what is wrong with the addon. When a match is found, Fx could cross-check with a central server (like SafeBrowsing). If the list cannot be updated, the last downloaded list is used. Before flagging an addon, it should be reviewed by Memshrink, Snappy, QA, Accessibility, AMO, etc. (where applicable) and the authors should be contacted. If no response by the author is received within 1 week (or 2, but not more [c2]), the addon will be added to the blacklist. An Addon should not be (hard/soft) blocked (as there is a different mechanism for that). When submitting an Addon to AMO, authors should be able to indicate "intentional bad performance" (e. g. leak-free Firebug) which is then considered by reviewers. Otherwise, there should not be a way to specify "intentional bad performance" by addon authors (but can be considered by reviewers / blacklist maintainers). Those rules should be publicly announced as "rules for providing addons to Fx users" [c2]. Possible warning / info texts (IMHO, the text does not need to be more specific than I propose below, whereas the flagging can be more specific): a) "This addon is known to perform badly, i. e. (causing memory leaks | slowing down or block Firefox | modify Firefox appearance in a bad way). [More information]" b) "This addon may slow down Firefox. [More information]" Where [More information] links to a Mozilla info / Q&A page explaining the meaning of the annotations and the addon guidelines. This feature is beneficial not only for Firefox, but also Thunderbird and all other Mozilla products, as well as WebApps [c3] or even Websites [c4]! [c1] A constant reminder of what causes Fx to behave badly will make users aware that Fx is not the source of the problem. This rule does not apply to (b) where a warning should only be shown *once* and always inside the addon manager. [c2] Publicizing a strict policy and timeframe will protect Mozilla from unfair complaints. [c3] WebApps are something completely different, and should not be covered by this bug (if this would ever be deemed a useful feature), but they might also behave badly in an unnecessary way. I only mention this to point out that the infrastructure and design for solving this problem should be problem agnostic, thus can easily be adapted to other use cases as well (however, it should not share the same infrastructure, i. e. WebApps should not appear on the "problematic addons"-list). [c4] See [c3]. Such a list can be used e. g. to inform users about websites that were written specifically for another browser (see e. g. CSS Vendor Prefix dilemma, and also IEs Compat Mode List). I didn't read any external links in this bug yet, so you might have already planned some of the behaviours I mentioned above. See this comment as a whishlist on the feature behaviour.

Bump This still has a major impact on users, with the blame typically ending up on Firefox, not on the broken addon, and causes some level of users leaving because "firefox is slow/buggy/unresponsive/memory-hog". Addons get added, but typically don't get removed unless they become incompatible or annoying (and incompatible is now less likely due to app compatibility changes). It would also let us finger users with non-AMO-installed addons known to be "bad" in some way, without being forced all the way to blocklisting

Yes. I understand the issues. This would still be a useful thing to have. But FF15 fixes the vast majority of memory leaks, so I don't think this needs to be a MemShrink:P1 any more. That's why I removed the ":P1", so we can re-evaluate it at the next MemShrink meeting.

Agreed - worth re-evaluation for memshrink. I do think it's an important company priority after seeing that list of top 100 addons and reading the related bugs, and now with compatible-by-default, older, unmaintained addons will linger much longer than they did over the last year, and if they bitrot (and start leaking due to core changes) it will be hard to deal with - doubly so if they're not AMO.

So... doing some recap here about bug 597282. Bug 597282 was stalled for a time because it was no clear where the data should came from. Then it was agreed that AMO would provide it, but was repeatedly coming with inconsistent naming in the OS field (and we were reluctant to do a mapping client-side). So basically it was stalled by a mixture of me not having enough time for it and comings and goings about where to finally get that data (and have it named properly). Now reading this bug, it seems the data that was half baked into the AMO API is no longer relevant? I would love to get the Addon Manager part of this solved by finishing up bug 597282, the only requirement is a clear place where to get the data from to know when to show the warning.

This may be of use: https://addons.mozilla.org/en-us/firefox/addon/about-addons-memory/ Very clear and useful.

Hi, is this still being looked at?

(In reply to bug.zilla from comment #31) > Hi, is this still being looked at? Not at the moment, I don't think so. The next big change we're implementing for add-ons is probably going to be bug 1047239 and its dependencies. Revamping the blocklist and having a fine-grained notification system is still very important, but we don't have enough people to tackle all of them at once.

Does this bug overlap with this? https://bugzilla.mozilla.org/show_bug.cgi?id=1071880

Mass-closing old Extension Compatibility bugs that relate to legacy add-ons or NPAPI plug-ins. If you think this bug is still valid, please reopen or comment. Sorry for the bug spam, and happy Friday!

I believe this feature would still be valid for the new extension format.

We don't have any plans to implement this. We're actually moving away from sending too much add-on data to clients, for performance and other reasons (see bug 1391792 and bug 1402064 for examples). It's also difficult and expensive to track non-critical issues in add-ons and keep them up to date. You're right that this is still valid for WebExtensions, but it should be a much smaller problem, and one that can be dealt with in other ways (better APIs, talking to developers, etc.).

This is much less of an issue than it used to be. We were primarily thinking about performance issues when this was filed, and while WebExtensions can still cause performance problems, they're much easier to mitigate with the OOP extension model and the actual privilege separations than they were with the wild-west-style legacy extensions. We already have specific prompts that we show when extension content scripts are dramatically slowing down web pages, and we'll likely add more such mitigations in the future. For extensions that cause memory consumption issues, this is even easier to detect and address on the client side than performance issues are, and I don't think a server-supplied list of trouble add-ons would be very useful there.