CTypes possible in WebExtensions?


my extension IsAdmin needs the ctypes library for its core functionality. It needs to call the Windows API to ask whether the application is running with Administrator privileges, so it can tell the user (that’s all the add-on does). Is anything like that possible in the new plans for add-ons?


1 Like

Short answer: No.

The only way this could currently be done with WebExtensions would be to ask the user to download and install a native executable, which the add-on could communicate with using nativeMessaging. But that seems like a total overkill in your situation. And you would have to detect the privileges of a different process than the current one, one yo don’t even know the process id or anything else than maybe a window name of.

Mozilla plans to add abstract APIs for specific tasks, but I highly doubt this will ever be among that.
So you can officially kiss your add-on good by once the everything except WebExtensions stops working in a year or so. But on the bright side, all other add-ons that do more exotic stuff will stop working too : )

Then it is as I feared. I am a heavy user of add-ons, so it looks like by that time, it will be time to look elsewhere for my browsing needs. Goodbye, old friend…

4 days ago there was an announcement that js-ctypes is banned.

You will have to use native messaging.

Pros of NativeMessaging

  1. MUCH MUCH easier, no need to declare all the type definitions and signatures of methods.
  2. Cross browser - you can start selling your addons and make your pocket win - Google Chrome and Edge is where the market is at.
  3. Its unreviewed by AMO staff - developer can do whatever you want to


  1. Major major limitation (ctypes did not have this issue) - many platform APIs must run in the target process.
  2. Major limitation of no Android support
  3. Requires “installation” even if we just need a 1kb exe that has a single function. Even if you place the exe within the extension it has no affect. You have to deliver it from a 3rd party source in an installer. This introduces major friction with users on the ease of use, discover-ability fronts.
  4. Unreviewed which leads to:
    • Users will not trust it, and will be afraid to download it
    • Reduces AMO integrity, as it puts on users un-reviewed material

I would say really check out Native Messaging, it’s pretty great if you ignore the cons. Here is a demo:

If you need help let me know I can step you through it. I was a total newbie to this and struggled through, I hope to help others avoid that struggle.

Hello friend, can you please give us more info on this (details, link) ?

Hey @susbox! :slight_smile: The message was over the dev-addons mailing list:

Hello all,

We just met to discuss the AMO plans for next year. Thanks to all who
attended! Here’s a summary of what we discussed.

Early in Q1 we’ll be landing a number of features that have been in the
works through Q4:

  • Developer landing page
  • Listed and unlisted version submission
  • New mobile website
  • Reviewer communication tool

Landing these features and the followups will take a good chunk of the
month of January.

For the remainder of the quarter, our top priorities will be the
following projects:

  • Support themes created with the new API.
  • Expose WebExtension permissions.
  • Restrict submission of legacy add-ons (after Firefox 53).
  • Discontinue usage of js-ctypes in add-ons.
  • Update linter with WebExtensions schema.
  • Support better screenshot submission and new banner image submission
    for add-ons.

Many of these projects are small, but there’s still plenty to do! Some
of them are pending PRDs, which I will be working on in the coming days.
I also updated the corresponding cards on trello:

Let me know if you have any questions!

Thank you noitidart. When do you expect to abandon the legacy addons? Will the js-ctypes support removed earlier, than the legacy addon support?

As a side-note, I only knew very few developers who have been using js-ctypes seriously. @noitidart is one, I’m another one, ochameau is another, but I believe that the list is not much longer. We can all confirm that js-ctypes is insanely powerful but also insanely complicated and bug-prone, as well as a major security risk (depending on where you’re using it).

I will be somewhat sad to see js-ctypes disappear but I personally believe that NativeMessaging is a much better choice for most use cases. Caveat: I’m not writing add-ons at the moment (rather, I’m contributing to Firefox itself) so I don’t necessarily experience the frictions involved.

1 Like

I use js-ctypes in FireShot for (300000 users). The most of the functionality is provided by native code. Switching to NativeMessaging would mean asking them to install the additional helper program, and this is a pain - I’ve already had to do this for Chrome, and I lost a lot of users :confused:

Note that when I meant “seriously”, I meant “lots and lots of lines of code that could have been written nicely in C (or Rust) but turned out really crappy in JS” – I should probably have found a better way to formulate it.

I understand the problem with requesting users to install a helper program. Unfortunately, I don’t see a better solution at the moment, though.

It looks like by end of 2017 both will be gone.

These were my thoughts, and I have seen the same sentiments by other ext devs (Google Chrome devs included).

What about a non-installation native messaging method? Where the dev places the binaries within their addon, and use the native messaging API like normal with it?


Ah, that would definitely solve this problem. I would vote for this with my both hands.


Haha, I vote with both my feet too. Our response is the same I have gotten from other native messaging developers.

Advantages of this method I see are:

  1. AMO review team can review the exe (ideally I would love the review team compiled it too)
  • Making users feel safe to download it
    • Maintain AMO’s integirty (as it used to be)
  1. Avoid users floundering/failing to install it
  2. Fix discover-ability issues:
    • Completely on addons.mozilla.org (AMO)
    • One click “Add to Firefox” (as it used to be) from AMO (with every click users make to get/run an installer we lose 20% of our users)

Let’s see what happens. I tried to explain this in the past but was discredited. Hopefully yours’ and other developers’ responses will help make this an option.

The review team has some pending discussion on native messaging. I’ll keep you updated on what I learn.

1 Like

That sounds like a good idea.


What about a non-installation native messaging method? Where the dev places the binaries within their addon, and use the native messaging API like normal with it?

Great idea. I do hope it would be implemented.
Thank you.


I vote for this no installation solution, but I hope also some API for I/O will be implemented

1 Like


Will the usage for js-ctypes also be discontinued?
I can’t imagine how addons like enigmail, which makes heavy use of it, could handle that…
Can someone give any info about that?

It was already discontinued :frowning: I don’t think any new addons will be accepted with it.

The only option is to set up native messaging. With an installer. Guaranteeing you will lose a lot of your user base. Installers are notorious.

  • The non-technical users can’t figure out how to install dependencies.
  • And the technical users know the material is unreviewed and unknown so won’t trust it, especially from a Jo Shmo and not a brand name like Google Microsoft (and the brands list ends a couple after these). (as a user I’m in this category, I don’t use anyone else native messaging work, I only use my own)

While this native messaging is ideal for sideloading, it is not good for small functions to tap platform APIs.

It is sadly the only option though. I can help you set it up if you need some help.

Oh, sorry I forgot to mention that I am asking for Thunderbird and ctypes…
Are thunderbird addons also affected?

I’m not sure about this one.