PSA: Ending support for chrome.input.ime on ChromeOS

[Darren Shen]

Hi everyone,

In M117 (scheduled to reach stable channel in September 2023), we are planning to remove support for the chrome.input.ime extension API.

The API was used to add custom input methods to ChromeOS. Unfortunately, this API is incompatible with the Lacros architecture where a user's browser can have distinct settings from the operating system. Removing the API also strengthens the operating system's security and privacy.

Based on our data, we expect this to impact only a small number of published extensions and we expect no wider impact.

If you have any concerns, please let us know.

Darren, on behalf of the ChromeOS Input Team.

[Ian Williams]

That's bad news, since I'm one of the "small number of published extensions" and it's an up-to-date, Manifest Version 3 extension. 

Is there any way that this can be replaced for migration purposes? Simply cutting off access to one of ChromeOS' core APIs is a little rough. We have paying customers, and having access to text snippets and translation from the keyboard has been a beloved feature of our users. 

[Ian Williams]

Just wanted to address this part, too: 

"Removing the API also strengthens the operating system's security and privacy."

That sounds a little unfair. Manifest Version 3 already did much to limit the capabilities of extensions, and Input.ime purposefully never worked in password fields. The initial activation also isn't easy, making it more of a power-user feature (which is who I've developed products for). Once you've activated it, deactivation can be done by pressing Ctrl + Spacebar, with ChromeOS telling users whether or not this third-party IME is still registering their keystrokes. 

Removing the ChromeOS IMEs also doesn't prevent attacks via the Android Runtime, which can still install (touch-only) Input method editors that read everything you type on ChromeOS tablets. Being that this is an expected use-case for applications on all platforms, I don't see why custom keyboards are a problem on ChromeOS.

You recently added support for ChromeOS IMEs in the Crostini container, moving us to further optimize our application for that. Did the team just realize that Lacros would make further advancements harder? Will Lacros kill the other system-based ChromeOS APIs (such as the wallpaper and new file-handling apis)? If not, couldn't this api be allowed to target ash-chrome, too?

On Tuesday, July 18, 2023 at 12:07:06 AM UTC-4 Darren Shen wrote:

[Darren Shen]

Hey extension developers,

Thank you very much for reaching out and voicing your concerns about our deprecation plans for chrome.input.ime support on ChromeOS. We’ve heard you loud and clear that, while usage may be low (< 0.01% of ChromeOS users), it provides a unique piece of functionality that is still very much desirable. Developer feedback like this is invaluable for informing discussions around how to best build a platform that meets your needs, and we’re sorry this announcement has caused so much concern. We’re currently having discussions about how to best move forward, and we’ll update you as soon as we can.

We appreciate your feedback, and will post a follow-up in 1-2 weeks.
Darren, on behalf of the inputs and extensions team.

[Ian Williams]

Thank you for hearing us, and—as a newer developer on ChromeOS—I hope we can turn those usage numbers around with more exposure for the Web Store on ChromeOS. There's a lot of awesome (and webby!) functionality packed into extensions that really enhances the ChromeOS experience, and input.ime is one of the best APIs for the platform. 

[Weizhong Yang]

Hi all,

I am the developer of a Chinese Zhuyin input method. This is my extension  小麥注音 (google.com) My extension dependes on chrome.input.ime. I did not notice the announcement until today.

I can understand the reason to remove the API. There are only about 300 users using my extension, and it seems removing the API does not affect lot of the users. However, custom input methods are critical for users in east Asia since users are often familiar with specific input methods to input text in their own languages. That's why I am porting a C++ based Zhuyin input method engine to ChromeOS, and I saw a Japanese developer ported SKK.

It's true. There are only few users are using custom input methods. I guess that's because Chromebooks are not popular in east Asia. I can easily find lots of Windows PC in various brands in the electronics stores in Taipei but I can hardly to find a Chromebook. However, custom input methods and this API are quite important if we want to promote ChromeOS in east Asia.

I would like to know, when deprecating the API, is there any replacement or a modernized input architecture. to let the developers to migrate to? Is there a roadmap?

Thanks!

Weizhong