Slashdot Mirror


Mozilla Will Deprecate XUL Add-ons Before the End of 2017

Artem Tashkinov writes: Mozilla has published a plan of add-ons deprecation in future Firefox releases. Firefox 53 will run in multi process mode by default for all users with some exceptions. Most add ons will continue to function, however certain add ons have already ceased to function because they don't expect multi user mode under the hood. Firefox 54-56 will introduce even more changes which will ultimately break even more addons. Firefox 57, which will be preliminarily released on the 28th of Novermber, 2017, will only run WebExtensions: which means no XUL (overlay) add ons, no bootstrapped extensions, no SDK extensions and no Embedded WebExtensions. In other words by this date the chromification of Firefox will have been completed. If you depend on XUL add ons your only choice past this date will be Pale Moon.

3 of 225 comments (clear)

  1. Great. by Anonymous Coward · · Score: 5, Insightful

    Why bother using this bloated browser when it drops support for the incredible addon library it's accumulated over the years? Without customization, what exactly does Firefox offer over Chrome?

    1. Re:Great. by higuita · · Score: 5, Informative

      Because current add-on design do not work with multi-process!!

      They are not ending the add-on, they must be migrated to the new API. Sadly many add-on are abandoned and will not be migrated. Others will not be allowed to do some functions, almost all of then must be rewritten. But the current add-on have fatal flaws and are doomed sooner or later.

      There are several problems with the current^WOLD add-on layer
      1- Old add-on have too much access to the firefox internals (security, memory leaks and performance problems)
      2- Old add-ons do not know how to work with multi-process and mozilla had to simulate a pool+lock for then to work (big lock, performance problems)
      3- Migrating code from Servo to Geko would break many add-on unless there are many compatibility layers (performance and code maintenance problems)

      Solutions:
      1-They could swap unsafe parts slowly and break many add-on on each release, forcing a slow and never ending add-on update cycle. It is much easier to just swap the API and warn that everyone must rewrite.
      2-Add-ons need to be fixed or else the browser will not really use the multi-process well and worse, may be even slower because of the big lock. If they remove the compatilbity layer, add-on stop working, but postponing the removal will keep the browser slower too and the add-on may never be updated (multi-process is already a several years project and all add-ons where flagged to be updated, but many are just abandoned). So wait more is not a solution, they need to be rewrite
      3-No one wants layers over layers, it is a maintenance hell, specially because the add-on have access to almost everything. Migrating to a simpler API make mozilla job much easier, firefox safer. Add-on will have to be rebuild and developers need to learn a new API. They will also be unable to do some things they can right now, but on the good side, it will much easier to port add-on between chrome and firefox and the add-on can be run in separated process, so bad add-on will be easier to stop and control.

      Yes, i too would like to keep all the add-ons, but between a fast browser with fewer add-ons and a slow one with many outdated add-ons, i prefer the first one. You can not complain about firefox being slow and also complain about keeping old add-ons. To fix one, you need to fix the other too! and you can not delay this, market share is shrinking due firefox being slower.

      They were making changes slowly, as they were mostly doing the last few years, and try to not break the add-ons, but you can not postpone a big internal change forever and now it is time to drop some old features, like NPAPI plugins and the old add-on interface

      What i hope is that mozilla is now more open to some features, as some features will be blocked to add-ons, mozilla need to be more flexible on certain features. The google design model ("only allow features that at least 80% of people use") is bad for firefox, as many of the users of firefox are the 20% of excluded people in chrome

      --
      Higuita
  2. An obviously bad move by iampiti · · Score: 5, Insightful

    The justification they've given for removing classic extension support is that they depend too much on the internals of Firefox, for the same reason they also said they're a security risk.
    They are valid technical reasons. Most people would agree that making extensions use a stable API decoupled from the browser's internals is a good thing for stability and compatibility in the long run.
    But, and this is a very big but, that means many popular current extensions can't just be made to work with the new APIs. Also, the ones that can be adapted will probably need a good amount of work. The result is that many extension developers have said they will abandon their extensions.
    Also, since those powerful extensions are one of the reasons many people keep using Firefox that will surely suppose a big hit on their maket share and that's the last thing Firefox needs.
    Their stated mission is to fight to keep the web open, if nobody uses their browser they'll have no money and no influence and hence they can't fulfill their mission.
    I know this must've been a hard decision to make at Mozilla but I feel it's not the right one.