8 ms·

I hate to be the person to say this, but perhaps a better approach would have been to simply create a build pipeline that iterated over the addons on AMO to fin

I hate to be the person to say this, but perhaps a better approach would have been to simply create a build pipeline that iterated over the addons on AMO to find the ones that use functions from the changed API and bulk send out an email about the changes to the authors (this eliminates steps 5 through 8). The addon developers then get the chance to change it or not. If it's broken oh well (eliminating steps 8 through 15). Making it the responsibility of the FF core team to sit on changes while waiting for a reply is a procedural problem not a problem with XUL/XPCOM. Moving to Web Extensions, which fundamentally make it impossible to access the full file system, permanently breaking many useful addons with no functional way to migrate to FF57 and calling that better is frankly dishonest.

Yoric 9y ago
> I hate to be the person to say this, but perhaps a better approach would have been to simply create a build pipeline that iterated over the addons on AMO to find the ones that use functions from the changed API and bulk send out an email about the changes to the authors (this eliminates steps 5 through 8). This would have automated steps 5 through 8, but not significantly reduced the problem. > The addon developers then get the chance to change it or not. If it's broken oh well (eliminating steps 8 through 15). 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 :) > Making it the responsibility of the FF core team to sit on changes while waiting for a reply is a procedural problem not a problem with XUL/XPCOM. It's a problem of the combination of having no API (i.e. XUL/XPCOM) and not wanting to break user's add-ons. > Moving to Web Extensions, which fundamentally make it impossible to access the full file system, permanently breaking many useful addons with no functional way to migrate to FF57 and calling that better is frankly dishonest. 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.
- xtraeme 9y ago
  > 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.
  - Yoric 9y ago
    > 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.
    - xtraeme 9y ago
      > 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).
- zakius 9y ago
  >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 :) but you did exactly that >Let's just say that we have different priorities. seems so, your priority became... trying to speed up hoping that people too dumb to care would switch back from chrome despite it's horrendous and unethical marketing while sacrificing everything that made your browser viable

Yoric 9y ago

> I hate to be the person to say this, but perhaps a better approach would have been to simply create a build pipeline that iterated over the addons on AMO to find the ones that use functions from the changed API and bulk send out an email about the changes to the authors (this eliminates steps 5 through 8). This would have automated steps 5 through 8, but not significantly reduced the problem. > The addon developers then get the chance to change it or not. If it's broken oh well (eliminating steps 8 through 15). 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 :) > Making it the responsibility of the FF core team to sit on changes while waiting for a reply is a procedural problem not a problem with XUL/XPCOM. It's a problem of the combination of having no API (i.e. XUL/XPCOM) and not wanting to break user's add-ons. > Moving to Web Extensions, which fundamentally make it impossible to access the full file system, permanently breaking many useful addons with no functional way to migrate to FF57 and calling that better is frankly dishonest. 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.

xtraeme 9y ago
> 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.
- Yoric 9y ago
  > 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.
  - xtraeme 9y ago
    > 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).
zakius 9y ago
>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 :) but you did exactly that >Let's just say that we have different priorities. seems so, your priority became... trying to speed up hoping that people too dumb to care would switch back from chrome despite it's horrendous and unethical marketing while sacrificing everything that made your browser viable