Add-on breakage, continued: List of add-ons that will probably be affected

May 23, 2013 § 20 Comments

Important note If you are a end-user, you are probably not affected. This is a call to add-on developers.

Developers of the following add-ons will need to update said add-ons to make them compatible with Firefox 25(update: we’re giving you some more time to fix stuff, so Firefox 27). Otherwise, these add-ons will most likely break:

  • MSN For Firefox
  • Bing For Firefox
  • Twitter
  • Tab Mix Plus
  • IE Tab
  • Undo Closed Tabs Button
  • SessionPage
  • Tab Scope
  • Taboo
  • Tree Style Tab
  • New Tab JumpStart
  • TabGroups Manager
  • Browse Periodically
  • Tab Utilities
  • Tile Tabs
  • IE Tab 2
  • Vertical Tabs
  • Master Password+
  • Home Dash
  • Extension Test
  • Progress Bar on Tab
  • Fox Splitter
  • Dormancy
  • Tabkit 2nd Edition
  • UnloadTab
  • Tabby2
  • Tab Restore
  • Side Tabs
  • Home Dash Lite-Dial
  • Fire IE
  • Tab Utilities Lite CustomEdition
  • Tabulous
  • Bar Tab Lite X
  • PageExpand
  • IE Tab 2 (SeaMonkey)
  • All Tabs Helper
  • multiplaceHolder
  • Suspend Tabs

All of these add-ons tap directly into undocumented, internal data structures that will disappear in the near future (expected: Firefox 27). If you are the author or maintainer of one of these add-ons, you should monitor carefully bug 874381 and its blockers for all technical details.

If you need technical help or if you need us to provide alternative public APIs, please get in touch as soon as possible.

Edit Added Suspend Tabs.

Edit Postponed to Firefox 27.

Edit I should have given more details about what exactly will break. We are progressively getting rid of all fields whose name starts with __SS. These add-ons are the add-ons that depend on such fields.

Edit Added a clarification about the audience of this blog post.

§ 20 Responses to Add-on breakage, continued: List of add-ons that will probably be affected

  • Caspy7 says:

    Will the “brokenness” of these addons affect our users’ experience adversely? (besides the obvious lack of expected functionality)
    In the past we’ve disabled addons which have excessively harmed user experience. Guess I’m just wondering if that might be necessary or not.

  • yoric says:

    Unfortunately, I have no way to predict this.

  • […] exist. For developers with add-ons that may be affected by this change, Mozilla has published a list and recommends that you check […]

  • bnvytd says:

    that sucks, going to google chrome

    • yoric says:

      Your call. Pick whichever browser you think better.

      Edit Just to clarify: this is a call for add-on developers so that they fix their add-ons before we release Firefox 25. Most users will probably never realize anything.

      • Ms. Sam Smith says:

        “Your call. Pick whichever browser you think better.”
        It looks like Mozilla is making the call FOR us–

        and “Most users will probably never realize anything.”

        THIS user spends most of her time trying to FIX things that have been broken, asking questions on the various boards. It is literally ALL I have done since V24.

        Feel free to look me up. I am “just an end-user” who has been *fiercely* loyal since the pre-AOL days, and what is happening just makes me sick.

        The whole POINT of Fx is it’s customization! Though I’ll be DAMNED if I go back to IE, Mozilla is making Chrome look better by the “upgrade”…

    • Caspy7 says:

      I can imagine this response from other developments, but in this case, these addons were using undocumented APIs (or perhaps “internal data structures”). The nature of these things is that they are intended for the internal workings of the browser and can change at any time from release to release without need for explanation (because no one else is supposed to be relying on them).
      It is considerate of Mozilla to those developers and users to even check, much less to give a heads up so they can prepare, when making a wholly internal change to the code.
      Yoric can correct me if I’m wrong, but it sounds to me like developers can follow that linked bug and may be able to prepare their code for the change in order not to be broken.

      • yoric says:

        That’s the idea. Also, they can get in touch (using the same bug, or through irc) and we’ll give them a hand to migrate their code.

  • Orhin says:

    My Solution.. I will not update anymore Firefox. Because only Versions Below V25 are serving purpose for Power Users and more advanced Users.

    Because right from V25 so many things are gone, that we will have indeed no more Firefox, but a “Firechrome” 😉

    And sorry, i want to have my customizations not removed, so i act in a way to preserve them for future usage!

    • yoric says:

      I have just clarified the blog post. This blog post was intended for the developers of the add-ons mentioned above, so that they can udpate their code before we release Firefox 25 and ensure that their add-ons do not break. Normally, as a user, you should not be affected.

    • Ms. Sam Smith says:

      There ya go–my thoughts exactly!

  • John G. says:

    Challenge accepted! Get the new TabGroups Manager at Google Project Hosting. Here, you’ll find our extended support program which covers Firefox 19 and beyond. https://code.google.com/p/tabgroupsmanager/

  • trlkly says:

    So, SuspendTabs does not use this functionality, even though it is the only one of the UnloadTab extensions that is supposedly using unmarked prefs?

    • yoric says:

      You are right, I forgot SuspendTabs from the list. Thanks.

      • trlkly says:

        Actually, having looked at the source code, it seems the author is already working around the problem, having replaced browser.__SS_restoreState with TabRestoreStates, imported from SessionStore.jsm. It doesn’t seem like browser.__SS_restore_data and browser.__SS_restore_tab don’t seem to have been removed yet, so the author doesn’t currently have anything to replace those with.

  • Adam says:

    “We do NOT break userspace! EVER!”
    –Linus Torvalds, lead developer of the most successful software project in world history

    ” ‘Oops,’ we broke your extension–again.”
    –Mozilla, organization behind what was once the most user-empowering browser in world history

    • yoric says:

      “We do NOT break userspace! EVER!”
      –Linus Torvalds, lead developer of the most successful software project in world history

      ” ‘Oops,’ we broke your extension–again.”
      –Mozilla, organization behind what was once the most user-empowering browser in world history

      Your remark is interesting. As you may have noticed, however, the above Linus quote (which I haven’t checked) does not apply to any Linux distribution that I know of. Whenever you upgrade your distribution, some of your static and shared libs, interpreters, compilers, headers, etc. will be replaced by more recent versions, some of your binary applications will break, some of your Python code will break, etc.

      As far as I can tell, these days, only Microsoft does the effort of ensuring long-term binary compatibility of code during system upgrades. We simply do not have the resources to do so – in particular, in this specific case, if you have read the blog entry, the problem is due to add-ons hitting directly into undocumented internal data structures. The authors certainly expected that their code would break, eventually. My blog entry gives them an approximate calendar for said breakage.

      What would you have done in this situation? Kept the code preserved in cryogenic stasis to ensure that no add-on would ever break? Or proceeded to modernize it, fix bugs and make it (much) faster?

      • trlkly says:

        I’d actually say that Mozilla mostly does a pretty good job with Firefox and its addons, at least, since moving to the faster update cycle. The big hiccup is Australis, which, for some reason, is apparently being implemented in an all-at-once manner, almost like the old full point version releases. You get the new UI, the limited buttons, the lack of the addon bar, and these internal changes all at once. (That is, unless Australis has been postponed yet again.)

  • Peter says:

    Honestly – I still stick to FF16 because with higher releases some of the extensions I use have a problem. Yesterday I spent THE WHOLE DAY to move to FF24 and had to give up in the end because some extensions had problems. On top of it the text rendering had problems. Yes, there are workarounds but I am getting tired to find such obvious problems like text rendering and to look for such workarounds. One even talking about uninstalling IE10…

    I am so tired that FF does not care about the extension developers and I can understand that they are getting tired too. Without extensions FF is absolutely nothing. After so many years Mozilla should know this. For me I set now the browser user agent in FF16 to FF24 so that some sites do not complain. But I guess FF16 will be my last version after so many FF years. I have tried too many times to upgrade – FF17, FF18 up to FF24 without success. But even before FF17 it was never easy.

    I am tired of this update game to check for hours all extensions if they still work and to find out in the end they do not. And I am tired of this many FF releases. Again – the only reason why I am using FF are the extensions. On my tablet without those extensions FF is not even installed anymore.

    • yoric says:

      I am sorry to hear that.

      Just so that you know, we care very much about extension developers. We have people working full-time on staying in touch with extension developers and ensuring that things work as smoothly as possible. Before we started changing Session Restore, we spent days tracking down all the add-ons that could possibly be broken by our change and trying to get in touch with the developers to work out solutions – through e-mail, IRC, forums and this very blog post.

      For this specific change of internal, non-documented, private data structures, we have been in discussion with the add-on developers we have managed to contact, to find workarounds, better solutions or new APIs that needed to be introduced prior to landing our changes. As far as I can tell, all such developers have been satisfied. If you are an unhappy extension developer, please get in touch with me or, even better, with Jorge Villalobos (jorgev on IRC), and we will see what we can do to make you happier.

      Now, what is true is that we need to break some APIs. We cannot afford to maintain full backwards compatibility, otherwise we will end up with a frozen icicle of the browser, stuck in the early 2000s, without any of the performance or features that just about everybody wants – including new features for add-on developers.

      P.S.: On the Android Store, Firefox is the highest-voted browser 🙂

Leave a reply to John G. Cancel reply

What’s this?

You are currently reading Add-on breakage, continued: List of add-ons that will probably be affected at Il y a du thé renversé au bord de la table.

meta