Mozilla has introduced a restrictive extension API similar to Chromium’s and announced the eventual deprecation of XUL- and XPCOM-based add-ons built on the existing Mozilla platform. XUL and XPCOM are both central to how AVIM for Firefox currently works and are what distinguish it from every other browser-based IME for any language, for any browser. Consequently, this announcement will mean several things for AVIM:

• The hoops I’m jumping through in [WIP] Make AVIM restartless #132 to make AVIM both restartless and backwards-compatible all the way back to Firefox 2.0 are for naught, cool as this effort may be.
• If history is any indication, Firefox will be the only Mozilla-based application that moves over to WebExtensions. A XUL-based AVIM will continue to be necessary for Thunderbird, SeaMonkey, Komodo, etc. But there will be a separate extension for Firefox, which offers a clean break from Firefox 2–34.
• transformer.js will be rewritten as a JSM, which offers all the reusability of XPCOM components.
• The preferences dialog will be rewritten as an about: page, since the existing Add-on Manager preference API is far too limited.
• The Mudim monitor is going away. Mozilla has committed to disabling add-ons that are incompatible with e10s, which should finally force Mudim off of Firefox Add-ons.

The architecture is going to look a lot different, but hopefully leaner.

Mozilla is collecting suggestions for WebExtensions APIs. At the moment, it looks like the following APIs are required, in order of priority, before AVIM can approach the current level of functionality:

1. An API for manipulating keystrokes in chrome, including inside other extensions’ contexts. Required for basic operation in the location, search, and find bars (among other controls), as well as for the application-wide double-Ctrl shortcut. Access to anonymous content may need to be part of this, since XUL controls contain anonymous HTML text controls.
2. An UndoManager DOM API enabled by default, so that synthesized inputs can be undone and redone. Required for reimplementing SpliceTxn, which is a Components.interfaces.nsITransaction.
3. A menu API, to add menu items to the Edit menu on all platforms, but particularly the native Edit menu on the Mac.
4. An API for manipulating about:config preferences. Important for persisting AVIM preferences across windows and sessions without resorting to ad-hoc solutions.
5. Along those lines, a Firefox Sync API, for keeping AVIM preferences synchronized across devices.

There are a few things I’m not sure of:

• Does AVIM need access to the nsIDOMNSEditableElement or nsIEditor? This access is currently required for implementing undo/redo, for coaelscing edits into transactions, and for doing all that very performantly and relatively elegantly. But maybe a WebExtensions API would obviate this approach?
• How will AVIM trigger a refresh of an input field’s autocompletion controller? It seems like Gecko would have to support a special DOM event rather than expose a special API.
• What are the implications for Sandboxes? AVIM relies on them to manipulate custom WYSIWYG editors without putting the rest of the extension at risk from those editors’ code.

CC’ing @osunick @jvillalobos