7 ms·

Unfortunately, this would have meant no Firefox Quantum. As a Firefox dev (I'm still working at Mozilla, although not much on Firefox atm), I have seen many, m

by Yoric 9y ago

Unfortunately, this would have meant no Firefox Quantum. As a Firefox dev (I'm still working at Mozilla, although not much on Firefox atm), I have seen many, many occurrences in which I couldn't optimize codepaths, or even in some case fix bugs, because the old extension mechanism made it impossible. Consider the necessary steps: 1. realize that an internal API is broken; 2. come up with a new non-broken API; 3. port all the internal code using the non-broken API; 4. add a compatibility layer between the broken API and the non-broken API; 5. check all the existing add-ons to find out which ones use the broken API; 6. hope you didn't forget any add-on; 7. attempt to get in touch with all the add-on developers; 8. repeat 7. many, many times, until you are sure that the add-on developers that do not respond have simply abandoned their add-on; 9. negotiate a transition plan with the add-on developer with whom you have managed to get in touch; 10. land the patch that you have written now 3-4 months ago; 11. maintain both the broken API and the non-broken API (and their tests) for ~1 year, until you are reasonably sure that all add-on developers who intend to migrate have done so; 12. maintain (and test) a downgrade path for people who switch between versions of Firefox; 13. finally land your code; 14. realize that you still have accidentally broken some add-ons and people are (rightfully) unhappy because "Firefox broke my add-on"; 15. it's 18 months since you wrote your 2-lines patch, you can finally get rid of the dead code and tests and move to something else. This was one of the reasons for which the Chrome teams managed to be faster and more efficient than the Firefox teams (well, that and a bazillion dollars to hire way more people). The add-on architecture is the main reason for which projects such as multi-processes only landed ~8 years after we had working prototypes and some other performance projects never landed at all. So, yes, removing the add-on architecture is definitely painful for a number of Firefox users, but I believe that we could not postpone it any further, even if it meant that some useful addons could not be ported immediately. Also, for what it's worth, we have postponed it by something like 7 years already :)

wpietri 9y ago
I'm sure you'll hear a zillion complaints, but I really appreciate you folks doing this. I've been using a beta version for the last few months on one of my computers and it's so very much better. I can't wait to have it everywhere. As long as you're here: I was told that the old extension API was way too broad, locking in a lot of design choices that were not really considered from the "do we want to maintain this for years and years" perspective. And that the new one is much more focused and considered. Is that the case?
- zbraniecki 9y ago
  Oh yes! It very much is :)
- Yoric 9y ago
  (thanks :) ) > As long as you're here: I was told that the old extension API was way too broad, locking in a lot of design choices that were not really considered from the "do we want to maintain this for years and years" perspective. And that the new one is much more focused and considered. Is that the case? Definitely. The old extension mechanism was basically "here is the toolkit we are using to build Firefox, come and plug anywhere/replace anything". If my memory serves correctly, at the time, Mozilla Browser/Firefox was (almost) the only browser doing any kind of extensions (I'm not counting M3 and a few experimental/academic browsers), so there was no real precedent on how to do this. For a time, it worked extremely well. After all, much of today's Firefox is built from add-ons that were progressively integrated in the browser. And then, progressively, we realized that there were drawbacks to this "anything goes" approach, but we couldn't fix things because that would mean breaking thousands of add-ons. So, after many years trying to postpone the inevitable for the sake of our users, we finally switched to a much better defined API. This WebExtension API is much smaller, much better documented, and does not expose internals-only stuff. Which means that now, we can fix internals-only stuff without breaking the API. Which should make the life of both Firefox developers, add-on developers and users much better :)
  - mook 9y ago
    I believe IE also had extensions (the channel bar in Windows 98, and later toolbars and ActiveX that partly lead to Firefox becoming so popular). It certainly didn't have as much flexibility as XUL though!
    - Yoric 9y ago
      That's possible. ActiveX was powerful but... problematic :)
  - slrz 9y ago
    Thank you for your work on Firefox. > This WebExtension API is much smaller, much better documented, and does not expose internals-only stuff. It also doesn't expose a lot of stuff that's useful and not tied to Firefox internals in any way. The browser is one of the most heavily used programs on people's computers. Integrating it with the rest of your system and workflow can have huge payoffs in user experience and productivity. The traditional XUL-based extension system, while not always pretty, allowed for that. WebExtensions are severely lacking here and some of that seems by design. As an example, I'm still trying to figure out a non-insane way to implement something akin to the It's All Text extension that allows editing text areas on websites using a proper text editor.
Already__Taken 9y ago
Also by moving ahead you are making the platform more valuable to get authors of plugins to come back and develop upon.
msla 9y ago
Did any of that require destroying the usability of the UI?
Anthony-G 9y ago
Many thanks for this informative post. I’ve read quite a few of the official Mozilla communications (announcements, blog posts, etc.) and so far, this has been the best explanation I’ve read for the impetus to move from XUL-based add-ons to WebExtensions. I write this from the perspective of a user who will lose almost half of their current extensions when they upgrade to 57.
- Yoric 9y ago
  Thanks :) (and sorry about your extensions)
xtraeme 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). 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.
hendersoon 9y ago
I'm sure you're absolutely correct in all the above, but I was happy with Firefox 56, then you broke mouse gestures so I stopped using Firefox and switched to Vivaldi. Whether alienating a huge number of formerly content users ends up increasing Firefox marketshare remains to be seen. But I won't be one of them.
firefox56 9y ago
Just rollbacked to firefox 56.
nar001 9y ago
I know it's not really the subject, but since you work at Firefox: Is Thunderbird still actively developed? Or basically on life support?
pluma 9y ago
Ignore the naysayers. Thank you for this. I've been dodging legacy add-ons already because they like to interfere with multi-process mode, killing Firefox's performance. Ubuntu's crappy legacy add-on actually nearly made me dismiss Firefox out of hand when I first gave it another try in February.

by Yoric 9y ago

wpietri 9y ago

I'm sure you'll hear a zillion complaints, but I really appreciate you folks doing this. I've been using a beta version for the last few months on one of my computers and it's so very much better. I can't wait to have it everywhere. As long as you're here: I was told that the old extension API was way too broad, locking in a lot of design choices that were not really considered from the "do we want to maintain this for years and years" perspective. And that the new one is much more focused and considered. Is that the case?

zbraniecki 9y ago
Oh yes! It very much is :)
Yoric 9y ago
(thanks :) ) > As long as you're here: I was told that the old extension API was way too broad, locking in a lot of design choices that were not really considered from the "do we want to maintain this for years and years" perspective. And that the new one is much more focused and considered. Is that the case? Definitely. The old extension mechanism was basically "here is the toolkit we are using to build Firefox, come and plug anywhere/replace anything". If my memory serves correctly, at the time, Mozilla Browser/Firefox was (almost) the only browser doing any kind of extensions (I'm not counting M3 and a few experimental/academic browsers), so there was no real precedent on how to do this. For a time, it worked extremely well. After all, much of today's Firefox is built from add-ons that were progressively integrated in the browser. And then, progressively, we realized that there were drawbacks to this "anything goes" approach, but we couldn't fix things because that would mean breaking thousands of add-ons. So, after many years trying to postpone the inevitable for the sake of our users, we finally switched to a much better defined API. This WebExtension API is much smaller, much better documented, and does not expose internals-only stuff. Which means that now, we can fix internals-only stuff without breaking the API. Which should make the life of both Firefox developers, add-on developers and users much better :)
- mook 9y ago
  I believe IE also had extensions (the channel bar in Windows 98, and later toolbars and ActiveX that partly lead to Firefox becoming so popular). It certainly didn't have as much flexibility as XUL though!
  - Yoric 9y ago
    That's possible. ActiveX was powerful but... problematic :)
- slrz 9y ago
  Thank you for your work on Firefox. > This WebExtension API is much smaller, much better documented, and does not expose internals-only stuff. It also doesn't expose a lot of stuff that's useful and not tied to Firefox internals in any way. The browser is one of the most heavily used programs on people's computers. Integrating it with the rest of your system and workflow can have huge payoffs in user experience and productivity. The traditional XUL-based extension system, while not always pretty, allowed for that. WebExtensions are severely lacking here and some of that seems by design. As an example, I'm still trying to figure out a non-insane way to implement something akin to the It's All Text extension that allows editing text areas on websites using a proper text editor.

Already__Taken 9y ago

Also by moving ahead you are making the platform more valuable to get authors of plugins to come back and develop upon.

msla 9y ago

Did any of that require destroying the usability of the UI?

Anthony-G 9y ago

Many thanks for this informative post. I’ve read quite a few of the official Mozilla communications (announcements, blog posts, etc.) and so far, this has been the best explanation I’ve read for the impetus to move from XUL-based add-ons to WebExtensions. I write this from the perspective of a user who will lose almost half of their current extensions when they upgrade to 57.

Yoric 9y ago
Thanks :) (and sorry about your extensions)

xtraeme 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). 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.

hendersoon 9y ago

I'm sure you're absolutely correct in all the above, but I was happy with Firefox 56, then you broke mouse gestures so I stopped using Firefox and switched to Vivaldi. Whether alienating a huge number of formerly content users ends up increasing Firefox marketshare remains to be seen. But I won't be one of them.

firefox56 9y ago

Just rollbacked to firefox 56.

nar001 9y ago

I know it's not really the subject, but since you work at Firefox: Is Thunderbird still actively developed? Or basically on life support?

pluma 9y ago

Ignore the naysayers. Thank you for this. I've been dodging legacy add-ons already because they like to interfere with multi-process mode, killing Firefox's performance. Ubuntu's crappy legacy add-on actually nearly made me dismiss Firefox out of hand when I first gave it another try in February.