Rewrite using WebExtensions API

[1ec5]

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 #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

[1ec5]

Firefox has had UndoManager support since Firefox 20, but disabled by default (dom.undo_manager.enabled).

[1ec5]

The lack of access to parts of the chrome outside Web content continues to be the major pain point for users of Chromium IME extensions, for instance kimkha/avim-chrome#19.

[1ec5]

@piroor filed some Bugzilla bugs that would be very useful for implementing #28 with a WebExtensions-based addon:

https://bugzilla.mozilla.org/show_bug.cgi?id=1353790 https://bugzilla.mozilla.org/show_bug.cgi?id=1276600

[1ec5]

An API for manipulating keystrokes in chrome, including inside other extensions’ contexts.

@cmcaine has written a WebExtensions experiment, keyboard-api, that would enable an extension to listen for and selectively suppress keystrokes. That’s half of what AVIM (or any input method extension) would need; the other half would be a way to manipulate the focused text field’s content, which would require synchronous communication.

[cmcaine]

Hi, does the keyboard API I've proposed meet your needs? Is any part of the API problematic for you? If you would prefer to IM, there's some contact details in the readme at https://github.com/cmcaine/tridactyl

Along those lines, a Firefox Sync API, for keeping AVIM preferences synchronized across devices.

You can do this with the storage API.

the other half would be a way to manipulate the focused text field’s content, which would require synchronous communication.

Are you sure you need synchronous comms for this?

[1ec5]

Thanks, I’m belatedly digging into the proposed API after having paid little attention to WebExtensions over the past couple years. (Nothing like a little time pressure!) I really appreciate the work you’ve done to get the proposal to this state. I’m trying to figure out whether an input method extension like AVIM should be within its scope or whether there should be a separate API.

Along those lines, a Firefox Sync API, for keeping AVIM preferences synchronized across devices.

You can do this with the storage API.

The original issue above was written at the outset of Mozilla’s WebExtensions effort, before the storage API was implemented.

the other half would be a way to manipulate the focused text field’s content, which would require synchronous communication.

Are you sure you need synchronous comms for this?

I may’ve been using the wrong terminology; I meant that it would be necessary for some extension code to run synchronously, since otherwise it’s possible for race conditions to arise. For example, suppose the user types ABC. “A” is captured by the extension and the default action is prevented, but “B” and “C” are allowed to have their default actions. Without some extension code running synchronously, it would be possible for “BCA” to be output. (There’s an annoying bug in Safari on macOS that illustrates this problem: if you hit ⌘F and type a search term, the word gets garbled every time due to that browser’s multiprocess architecture.)

Following the Electrolysis migration, AVIM solves this problem by loading the same frame script into both chrome and frame contexts. When loaded into chrome, the script communicates synchronously with chrome code, but I don’t know if that’s possible with WebExtensions.

Beyond the keyboard API itself, there’s the bigger issue of how to manipulate the contents of chrome text fields like the URL bar or search bar. This functionality would be crucial to any input method extension. With Mozilla moving away from XUL, I imagine they’d be hesitant to provide direct access to chrome text fields, but perhaps that means a higher-level input method API might need to be designed.

[timph]

You did a great job with this add-on. I missed this after updating to Firefox 57. I surely hope to see it again in the next version.

[tuanpht]

Hi @1ec5, can we have basic version of AVIM for the new Firefox first. Advanced features will be added later (if Firefox provides more API).

I am currently using ViolentMonkey to load avim.js into some websites which I need to type Vietnamese, which is not so convenient.

Thanks for great add-on.

[1ec5]

Thank you everyone for your patience. By way of an update, addons.mozilla.org plans to remove all legacy extension listings soon, including AVIM, but Thunderbird users can continue to find AVIM on Thunderbird Add-ons. I haven’t had the time to make much progress on porting AVIM to WebExtensions, but I hope to in the near future. Part of that will be investigating whether a WebExtensions API specifically for input methods would be feasible, since the more general-purpose keyboard API proposal hasn’t gotten any traction yet: cmcaine/keyboard-api#1.

I know it’s frustrating that there isn’t an addon like AVIM available in recent versions of Firefox, but please do not install the “Vietnamese Input Method” extension by domdomrung, which is spyware that somehow got approved by AMO reviewers. (It goes to show that an extension environment that’s designed for security and privacy can still be quite vulnerable to attacks. It’s a bit frustrating for me personally, because every submission of AVIM has always attracted lots of scrutiny from AMO reviewers who misunderstand this addon’s privacy and security safeguards.)

To keep rogue addons from attracting more users, I’m willing to accept a pull request that adds WebExtensions support using a simple content script, as a temporary workaround for the lack of input method functionality in WebExtensions. I’m not sure if it’s still possible for a single XPI to contain both a legacy extension implementation and a WebExtension, but it would be ideal to avoid a fork between the Firefox and Thunderbird/Komodo versions of AVIM.

[cmcaine]

You can bundle a legacy extension as a webext experiment with your webext, but it can only be loaded on nightly/developer with an appropriate about:config switch set.

On Sat, 1 Sep 2018, 13:34 Minh Nguyễn, notifications@github.com wrote:

Thank you everyone for your patience. By way of an update, addons.mozilla.org plans to remove all legacy extension listings soon, including AVIM, but Thunderbird users can continue to find AVIM on Thunderbird Add-ons https://addons.thunderbird.net/vi/thunderbird/addon/avim/. I haven’t had the time to make much progress on porting AVIM to WebExtensions, but I hope to in the near future. Part of that will be investigating whether a WebExtensions API specifically for input methods would be feasible, since the more general-purpose keyboard API proposal hasn’t gotten any traction yet: cmcaine/keyboard-api#1 https://github.com/cmcaine/keyboard-api/issues/1.

I know it’s frustrating that there isn’t an addon like AVIM available in recent versions of Firefox, but please do not install the “Vietnamese Input Method” by domdomrung, which is spyware that somehow got approved by AMO reviewers. (It goes to show that an extension environment that’s designed for security and privacy can still be quite vulnerable to attacks. It’s a bit frustrating for me personally, because every submission of AVIM has always attracted lots of scrutiny from AMO reviewers who misunderstand this addon’s privacy and security safeguards.)

To keep rogue addons from attracting more users, I’m willing to accept a pull request that adds WebExtensions support using a simple content script, as a temporary workaround for the lack of input method functionality in WebExtensions. I’m not sure if it’s still possible for a single XPI to contain both a legacy extension implementation and a WebExtension, but it would be ideal to avoid a fork between the Firefox and Thunderbird/Komodo versions of AVIM.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/1ec5/avim/issues/141#issuecomment-417856734, or mute the thread https://github.com/notifications/unsubscribe-auth/AFuQeSocoi6zue0oVGKMPjPYgyanbGEqks5uWn7ygaJpZM4FwSsE .