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:

• Allow extension authors to provide a manifest of GUIDs, or something similar, they depend on. These are the actual interfaces they use.
  • Either the browser itself, or else a.m.o. or similar need to be able to tell you whether a given Firefox release supports a particular set of IDs.
  • For people trying to be compatible with multiple versions, there may need to be more complex behavior than a simple list, such as "ID x and (y or z)".
  • Some things people want to do may not currently correspond to actual APIs/interfaces/things with GUIDs. Perhaps we'd need to encapsulate some "non-API" concepts in here?
  • Perhaps an automated tool (nontrivial!) could be written to generate a list of GUIDs from some code, in order to ease manifest creation? This is probably too hard to be worth it
• Use a known, publicized set of "stable interface GUIDs" 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.

Manpower is always a problem when tackling issues like this, but the current human interaction model isn't working and doesn't scale. An automated system that, if necessary, falls back on the version numbering system we have now would be a strict improvement.