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

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.

Advertisements

Like this:

LikeLoading...

Related

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

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.

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.

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.

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.

“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?

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

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.

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.