> Ah, well, sure, in that case, randomly breaking add-ons all the time would indeed have made our life easier. But everybody else's life would have been much worse, so we decided not to do that :)
This is the part that I think you are going to get the most flak for. People are willing to deal with temporary setbacks if the changes can be brought in at some point. Permanently breaking things and calling that better will get the Mozilla Foundation a mountain of angry hate mail from people who committed to the platform.
> Let's just say that we have different priorities. While it's not as powerful, it's better for security, performance, privacy, bugs and future-proofing.
I have no problem if the Mozilla Foundation or the Firefox team has different priorities, but say that rather than telling technical people the reason for the changes is because XUL or XPCOM are somehow so hideous the team had no choice. It smacks of dishonesty when everything that you have described here is a problem with procedure not anything technical.
> I have no problem if the Mozilla Foundation or the Firefox team has different priorities, but say that rather than telling technical people the reason for the changes is because XUL or XPCOM are somehow so hideous the team had no choice. It smacks of dishonesty when everything that you have described here is a problem with procedure not anything technical.
Well, some of our priorities with WebExtensions are (not necessarily in this order):
- stable, documented, future-proof API;
- improving security;
- improving performance;
- improving privacy.
You are, of course, free to consider these things "not anything technical", but they were impossible as long as add-ons weren't based on an API at all.
So, again, while I fully realize that there is a cost, I believe that we're moving from something unsustainable to something sane, which makes it better in the long run.
> I believe that we're moving from something unsustainable to something sane
It is only unsustainable because the FF team chose to make the process more difficult than it had to be. This is how what you are saying sounds:
1. We didn't want to break plugins so we involved addon developers
2. The process takes so long that it takes 18 months to introduce any new code
3. Since 2 was so slow we decided instead we would PERMANENTLY break plugins with no way to ever fix them
Put another way: things were taking too long because of Mozilla's own self-imposed guidelines so the Firefox team had no choice but to PERMANENTLY break addons that will never be fixable by design because the Firefox team was so concerned about temporarily breaking plugins. This is double speak. The predicate (3) contradicts the subject (1).
After it was pointed out how ludicrous this sound the caveat is added that this had to be done in the name of security, performance, and privacy. At what point did security and performance become more important than an open platform and why? Numerous addons exist solely to provide privacy by blocking fingerprinting, stopping redirects, providing control over cross-site requests (RequestPolicy Continued), super-cookie safeguards (BetterPrivacy), and these options are no longer available. How are these privacy enhancing features being added now that the option has been removed since the goal is privacy?
The whole thing is hard to take at face value when everything seems to be self-contradicting (sans performance).
Looks like we're both running out of arguments, since we're both essentially repeating ourselves, so I'm going to admit that I'm not going to manage to convince you :)
I am not trying to be hard on you. I know you likely don't have any real say in the process, but as one of the senior developers at the Mozilla Foundation you have an opportunity to call out shenanigans when you see it.
First we hear the changes are because adding new code took too long because the team didn't want to break addons, yet WebExtensions does just that in ways that are far worse than just temporarily breaking addons.
Second we hear it's about privacy. Yet WebExtensions breaks a large number of privacy plugins that won't be ported. There is also the Cliqz partnership and the October experiment. "In August 2016, Mozilla ... made a strategic investment in Cliqz. Cliqz plans to eventually monetize the software through a program known as Cliqz Offers, which will deliver sponsored offers to users based on their interests and browsing history."[1] "Mozilla is experimenting with including the Cliqz plug-in by default in its open source Firefox browser."[2] The reader can decide for themselves whether or not this is in the interest of privacy.
All that is left then to explain the changes are possibly security and speed. Security I am not so sure about as privacy and security tend to go hand in hand. It would be nice if you could respond to the earlier questions. FF57 is noticeably faster however so that is at least believable.
Whatever the real story is I do appreciate you engaging with us because you have no obligation to be here and you deserve respect for that.
The browser internals aren't userspace. Web Extensions are userspace. The browser internals are more like kernel space, which the Linux kernel breaks, all the time [1].
Indeed, if you provide an API you'd better commit to it. The difference is that before WebExtensions, there was no API. Everybody was just hooking into the internals.
That's not "do not break userspace" – which makes sense – that's "do not change anything, ever" – which is project suicide.
Now, with WebExtensions, there is a difference between the API and the internals, so we can commit to something. And, while there is a cost to this change, that's definitely a much, much, much better base for developers on both side of the API.
Mozilla pitched the Add-on SDK to developers as that kind of API. It was deprecated less than a year ago with no migration path and a half-baked replacement.
This is the part that I think you are going to get the most flak for. People are willing to deal with temporary setbacks if the changes can be brought in at some point. Permanently breaking things and calling that better will get the Mozilla Foundation a mountain of angry hate mail from people who committed to the platform.
> Let's just say that we have different priorities. While it's not as powerful, it's better for security, performance, privacy, bugs and future-proofing.
I have no problem if the Mozilla Foundation or the Firefox team has different priorities, but say that rather than telling technical people the reason for the changes is because XUL or XPCOM are somehow so hideous the team had no choice. It smacks of dishonesty when everything that you have described here is a problem with procedure not anything technical.