Extension compatibility ideas

There are currently a lot of problems with extension compatibility in Firefox.

• Versioning was introduced to allow continued API flexibility, but it doesn't solve the problem well
  • Because things can change in arbitrary ways between releases, authors must retest their extensions and attempt to observe if things still work
  • Older extensions naturally rot and become prematurely unusable unless they're continually maintained
  • The requirement for human interaction means Firefox does not tell users if an extension is _actually_ incompatible, only if someone has manually marked it _compatible_, which isn't the same
• Users do not understand this issue and it negatively impacts their behavior
  • Firefox appears to tell them extensions are _actually_ incompatible, which makes them believe they truly are more than is really the case, which makes them believe extensions aren't ever going to be compatible with any upgrades
  • Users using extensions care a lot about their extensions, so this means they don't like upgrades, since upgrades (that they aren't eager for) have always broken their extensions
  • The dislike for upgrades, coupled with the frustration of the browser "breaking my extensions all the time", lead to lowered user satisfaction and less security

So, the ideal solution would be "never break extensions" and the less-ideal, but still improved solution, would be "make Firefox say my extension is incompatible if and onyl if it is actually incompatible". Our current system makes no attempt at the first of these, and only accomplishes the second with significant and continued human interaction.

In addition, extension authors don't have a well-specified "best way" of doing various common tasks, which is also a negative:

• Authors need to research how to do things instead of using simple, available documentation
• Authors do things many different ways, possibly causing obscure bugs by hooking into seldom-used or unintentionally public functionality
• There is no consistency between extensions and the browser or extensions and each other in terms of the user experience

Here is a suggestion for how to address all these issues, in two parts:

• Create an automated tool which, given an extension, attempts to scan for use of known-frozen/stable APIs versus "other" (i.e. functionality not known to be frozen/stable). Use this tool as part of the a.m.o. submission process and stamp the results into the extension somewhere or into an accessible online database.
  • The results of this tool allow us to see, regardless of version string, that a specific extension is likely to still work with a newer Firefox, because none of its APIs have been broken.
  • An enhanced version of the tool, which records what APIs are actually used instead of just stable vs. unstable, could then be coupled with information about "these APIs have changed in this Firefox version" to also mark "compatible" extensions that use unstable but unchanged APIs.
  • Currently, this tool will not be much use, because a very small set of functionality is actually stable, and even common tasks like creating XUL overlays might trigger the "unstable" flag.
  • This tool is nontrivial to create.
• Use the automated tool as a reward path to get people to use stable APIs (since their extensions will no longer break), and make that an achievable goal by beginning to standardize more functionality.
  • Supposedly, IE has a richer set of public APIs for folks writing extensions/BHOs. Perhaps we could learn from what they've done.
  • A standardized way to, say, add an item to a menu means we can enforce more UI consistency. Carefully chosen APIs mean we can also discourage dangerous or less-usable functionality/design.
  • Because "unstable" extensions still work, there's no need to try and provide a frozen interface to everything anyone could possibly want; we can cherry-pick desired functionality and provide it at any desired pace. Thus this design doesn't require a lot of "big bang" implementation and allows us to proceed carefully on the API work.

And now some more editorial comments from me (pkasting): I proposed something like this on #developers and received a lukewarm reception, but I suspect that was due to

• Only speaking of the automated tool portion, not the stable API reward path portion
• General reluctance on the part of developers to go anywhere near ideas like "stable APIs"
• A lack of developer interaction with extension developers, and a lack of understanding of the problems of extension developers

I'm certainly open to suggestions on how the problems I give at the beginning can be addressed, but I think they do _need_ to be addressed. The human interaction model we have now clearly does not work well enough to prevent a lot of user frustration among extension users, and I think it lowers the numebr and quality of extensions as well. While the ideas described here would take a great deal of effort to implement, I think they would be worth persuing over the course of several release cycles.