-
Notifications
You must be signed in to change notification settings - Fork 4
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
Comments
Firefox has had |
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. |
@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 |
@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. |
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
You can do this with the storage API.
Are you sure you need synchronous comms for this? |
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.
The original issue above was written at the outset of Mozilla’s WebExtensions effort, before the storage API was implemented.
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. |
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. |
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 Thanks for great add-on. |
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: tridactyl/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. |
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, ***@***.***> 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: tridactyl/keyboard-api#1
<tridactyl/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” 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
<#141 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFuQeSocoi6zue0oVGKMPjPYgyanbGEqks5uWn7ygaJpZM4FwSsE>
.
|
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 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:
UndoManager
DOM API enabled by default, so that synthesized inputs can be undone and redone. Required for reimplementingSpliceTxn
, which is aComponents.interfaces.nsITransaction
.There are a few things I’m not sure of:
nsIDOMNSEditableElement
ornsIEditor
? 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?Sandbox
es? 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
The text was updated successfully, but these errors were encountered: