CTypes possible in WebExtensions?

Add-ons Development
#6

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:
https://trello.com/b/ZpIDuMAW/addon-planning

Let me know if you have any questions!

#7

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

#8

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
#9

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:

#10

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.

#11

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?

3 Likes
#12

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

2 Likes
#13

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
#14

That sounds like a good idea.

2 Likes
#15

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.

2 Likes
#16

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

1 Like
#17

Hey,

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?

#18

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.

#19

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

#20

I’m not sure about this one.

#21

“Mozilla Executive Chair Mitchell Baker announced […] that Thunderbird development needs to be uncoupled from Firefox. [Due to] developers spending large efforts responding to changes to Mozilla technologies” - Wikipedia

Implementing WebExtensions (and deprecating everything else) would definitely be such a large effort. I doubt that’s going to happen in a software that hasn’t seen any major changes in years.

1 Like
#22

You can still use ctypes on Thunderbird and SeaMonkey add-ons. There are no plans to implement WebExtensions APIs on either of them.

1 Like
#23

Ah, I hoped to switch to WebExtensions and forget about the ctypes… :confused:
Does that mean, that I still need to maintain both versions of the extension?
What is the best approach to switch my Firefox users to WebExtensions without losing the auditory of Thunderbird and Seamonkey?

#24

There aren’t many good options at present and I suggest that you hold off taking any action for now. We’re talking to the Thunderbird Council about some possibilities and should have something we can announce in the next month or so.

#25

Thanks Jorge. Having solution for Seamonkey would be also welcome.