Compatibility Update: Add-ons on Firefox for Android

Jorge Villalobos

13 responses

We announced our plans for add-on compatibility and the transition to WebExtensions in the Road to Firefox 57 blog post. However, we weren’t clear on what this meant for Firefox for Android.

We did this intentionally, since at the time the plan wasn’t clear to us either. WebExtensions APIs are landing on Android later than on desktop. Many of them either don’t apply or need additional work to be useful on mobile. It wasn’t clear if moving to WebExtensions-only on mobile would cause significant problems to our users.

The Plan for Android

After looking into the most critical add-ons for mobile and the implementation plan for WebExtensions, we have decided it’s best to have desktop and mobile share the same timeline. This means that mobile will be WebExtensions-only at the same time as desktop Firefox, in version 57. The milestones specified in the Road to Firefox 57 post now apply to all platforms.

13 responses

  1. Wladimir Palant wrote on :

    Yay, our QA department will be insanely happy about that – now we’ll have to rush an implementation for mobile as well that they’ll get to test. Our existing Chrome codebase was never meant for mobile, adjusting the UI is going to be fun.

  2. Ulf3000 wrote on :

    pleaase tell me theres a hidden option to still enable legacy addons beyond ff57 , i have ff54 with enabled multiprocessing and sandbox and all old addons i have intalled , be it sdk or xul based, are running fine

    1. Jorge Villalobos wrote on :

      There won’t be any way to load legacy add-ons in release versions of Firefox past 57.

      1. Ulf3000 wrote on :

        but youre just removing the sdk modules and bootstrap file , id just leave it in until lagecy addons break in the future by itself (which could still be years depending on the addon ) , people with legacy addons know what they are doing anyways , like i said sanboxing and multiprocess (more than one content process) don´t affect most good addons negatively .

        if i were you id just remove all the broken addons from the amo page one by one , i stumbled over so many addons over the years which don´t work anymore and will never be updated again anyways which could just be removed .

        on one hand you allow tracking practices , data colection etc. BECAUSE TEHY USE SAFE METHODS , lol
        then you say the privacy addon devs are evil they aren´t allowed to use unsafe methods hrrm

        1. Ulf3000 wrote on :

          I mean even your own TESSTPILOT extensions are bootstraped extensions!!! and thats also whta i was told on the irc channel , that firefox internal extensions will still be bootstrapped for the time , so the bootstrap loader and everything will still be shipped with firefox so justy make an optionm to enable legacy addon on will

        2. Jorge Villalobos wrote on :

          It’s better for both users and developers to have clear deadlines than just wait for things to progressively break. It’s also better for stability in the product and for Firefox developers to know what they can or can’t break in the future. Many things will break after 57, since Firefox developers won’t need to worry about legacy add-ons.

          It’s true that some internal add-ons will still have access to internals, but the majority are being migrated to WebExtensions and the expectation is that legacy internal add-ons will be very rare.

  3. Andrei wrote on :

    I can’t wait to get rid of all the XUL addons and be all WebExtensions 😀 I really like the new APIs. I like the fact that they are only async, simple, cross-browser and have fine grained permissions.

    1. Ulf3000 wrote on :

      I think you don´t know what you´re talking about TBH !

      I you ever made a addon yourself , you´d know how javascript works , that async is just a buzzword , the new api are not simple at all , that at their core they are programmed in xul/ctypes( just a ton more uneffiecient than the sdk) , have less power and lots of overhead

      1. Jorge Villalobos wrote on :

        I have to disagree. You can’t get more inefficient than the SDK.

    2. that-random-guy wrote on :

      You and only you.

      The only ones who approve of the changes are apparent: it’s the devs.

      You guys get all the spoils and grandeur while the rest of us get hardly any replacement or substitute for things we need to safely and routinely use the product.

      They’re removing a lot things we never asked them to remove.

      Unless the new theme implementation will allow for what CTR does, then there really isn’t a replacement there.

      What I still don’t understand is how touching the UI has an consequence on the browser’s ability to perform it’s tasks in the proficient manner they are seeking.

      1. walty wrote on :

        To be fair, at least developing Firefox WebExtension is very much similar to Chrome Extension (I just tried to do one migration myself). One could very easily develop for both platforms now, which is a big advantage for many developers.

        And the debug cycle is much easier now, even when compared to jpm (never tried XUL).

        The WebExtension API is not perfect, but it’s indeed a standard that has been used for long time (by Chrome) now.

        My only complaints:

        1. the review cycle is really slow now.. (4 weeks passed since the submission of app update and I am still in the middle of queue)

        2. I wonder if Selenium IDE would be allowed survive after Firefox 57.

  4. Aris wrote on :

    Will the current user interface also switch to “Photon” like desktop Firefox with version 57 and offer squared tabs, buttons in location bar etc. or will it stay the way it is now?

    1. Jorge Villalobos wrote on :

      I’m not aware of a plan to apply a Photon-like UI on Android, at least not at the same time as desktop Firefox.