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?
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
MUCH MUCH easier, no need to declare all the type definitions and signatures of methods.
Cross browser - you can start selling your addons and make your pocket win - Google Chrome and Edge is where the market is at.
Its unreviewed by AMO staff - developer can do whatever you want to
Cons
Major major limitation (ctypes did not have this issue) - many platform APIs must run in the target process.
Major limitation of no Android support
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.
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.
Hey @susbox! 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: Trello
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.
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
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.
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?
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.
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.
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 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.