Manifest V3 support

[derat]

Per https://developer.chrome.com/blog/mv2-transition/, Chrome will stop running Manifest V2 extensions in January 2023.

example/xkb/manifest.json contains "manifest_version": 3, but some of the other layouts (like dvorak-intl/manifest.json) still use V2.

I manually changed the version in my local unpacked copy of the dvorak-intl extension, and it seems to still be working after reloading it via chrome://extensions/. One caveat is that the input method disappeared from the system area after the reload (I usually switch between the builtin "English (EN) with Dvorak keyboard" layout and "Dvorak International", but after I opened the "Languages and inputs" system settings and clicked on one of the layouts, it was shown again.

If it'd be helpful, I can create a PR updating the remaining manifest.json files, but I don't know if any other changes are needed (since the input_components property in manifest.json seems to still be undocumented). :-/

[LaPingvino]

Yeah, I submitted the Dvorak-Intl at the time, and it is now indeed removed, sorry about that, also saw this issue way too late. Feel free to correct this, submit a PR for this repository and maybe even reupload the updated keyboard to the Webstore. I would love to start using it again, now for the time being using the Compose Key dvorak instead...

[derat]

Thanks for the reply; I've created #131.

It might be better if someone with access to the chrome-input-extensions webstore account uploaded this so all the extensions are in one place, but I can upload it to my account if that'd be easiest.

[derat]

It took some back-and-forth with the web store reviewers (I think they're unfamiliar with the chrome.input.ime API), but I eventually got a Dvorak International extension approved: https://chrome.google.com/webstore/detail/dvorak-international/bmelnadochjnkdciehdnnlnpejmjolgo

I think that there are ~20 manifest files in the repo that still have manifest_version set to 2, so this issue should probably remain open. (I don't plan to try to update them since I'm not sure how to test them all.)

[LaPingvino]

Thank you so much! 😃 On June 21, 2023 at 12:36 GMT, Daniel Erat ***@***.***> wrote: It took some back-and-forth with the web store reviewers (I think they're unfamiliar with the [chrome.input.ime API](https://developer.chrome.com/docs/extensions/reference/input_ime/)), but I eventually got a Dvorak International extension approved: https://chrome.google.com/webstore/detail/dvorak-international/bmelnadochjnkdciehdnnlnpejmjolgo I think that there are ~20 manifest files in the repo that still have manifest_version set to 2, so this issue should probably remain open. (I don't plan to try to update them since I'm not sure how to test them all.) — Reply to this email directly, [view it on GitHub](#120 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAACQNRMRRRUTFCML4O3JNLXMLTF3ANCNFSM5YQLIBSQ). You are receiving this because you commented.Message ID: ***@***.***>

[gutschke]

This seems to also affect the ComposeKey extension.

Please consider uploading a fixed version. Thank you

[derat]

@gutschke: Long time no see! I'm not a maintainer of this repo, but the composekey extension uses a background script rather than just specifying an XKB layout. IIUC Manifest V3 requires background scripts to be converted to service workers, so fixing it will probably be more work.

These extensions all look like they use background scripts:

• bepo
• capslockremap
• composekey
• dvorakleft
• dvorakright
• esperanto
• german-comma-on-numpad
• lushootseed
• ukextended

[gutschke]

@derat, good to hear from you too :-)

This is all code and APIs that I am not particularly familiar with, and I only took a very high-level look at trying to understand the issues. The link that you posted is helpful in general, but it unfortunately doesn't directly answer how to get access to the KeyboardEvent object that is needed for this extension. I hoped that an offscreen document might do the job, but if I read things correctly, it is not the correct solution either.

I made a very half-assed attempt at trying to fix everything that was throwing errors. Clearly not a good engineering practice at all. But it did result in an extension that superficially appears to work again, although I suspect that the synthetic events that it generates are technically malformed, as they don't have a proper "location" field. It doesn't seem to break too many things, but that's maybe a bit of wishful thinking on my part.

I also somewhat blindly converted to the Chrome-specific storage API. But I don't know enough about how these APIs work to tell whether this is a sane approach, or whether I am now stomping on the synchronization API which looks very similar and might or might not be interfering.

You can see my work in #147. I honestly have no idea if this is anywhere close to the correct approach or whether it's just an ugly hack. That's why I didn't make it a pull-request. Way too embarrassed to have this code pulled indiscriminately. But maybe, it's a good start for a discussion with somebody who actually knows that they are doing?