Compatibility Update: Add-ons on Firefox for Android

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.

9 responses

Post a comment

  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.

    Reply

  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

    Reply

    1. Jorge Villalobos wrote on :

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

      Reply

      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

        Reply

        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

          Reply

        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.

          Reply

  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.

    Reply

    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

      Reply

      1. Jorge Villalobos wrote on :

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

        Reply

Post Your Comment