New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rewrite using WebExtensions API #141

Open
1ec5 opened this Issue Aug 22, 2015 · 10 comments

Comments

Projects
None yet
4 participants
@1ec5
Owner

1ec5 commented Aug 22, 2015

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 1ec5 added the applications label Aug 22, 2015

@1ec5

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Aug 22, 2015

Owner

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

Owner

1ec5 commented Aug 22, 2015

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

@1ec5 1ec5 referenced this issue Aug 23, 2015

Closed

[WIP] Make AVIM restartless #132

16 of 28 tasks complete
@1ec5

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Apr 23, 2016

Owner

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.

Owner

1ec5 commented Apr 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Jul 22, 2017

Owner

@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

Owner

1ec5 commented Jul 22, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Sep 25, 2017

Owner

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.

Owner

1ec5 commented Sep 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cmcaine

cmcaine Sep 25, 2017

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?

cmcaine commented Sep 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Sep 25, 2017

Owner

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.

Owner

1ec5 commented Sep 25, 2017

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.

@1ec5 1ec5 referenced this issue Oct 10, 2017

Closed

ff 58 #185

@timph

This comment has been minimized.

Show comment
Hide comment
@timph

timph Nov 17, 2017

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.

timph commented Nov 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tuanpht

tuanpht Mar 2, 2018

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.

tuanpht commented Mar 2, 2018

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

This comment has been minimized.

Show comment
Hide comment
@1ec5

1ec5 Sep 1, 2018

Owner

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.

Owner

1ec5 commented Sep 1, 2018

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

This comment has been minimized.

Show comment
Hide comment
@cmcaine

cmcaine Sep 1, 2018

cmcaine commented Sep 1, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment