Extension conflicts, 2009 edition · 2009-11-24 11:01 by Wladimir Palant

I realized something yesterday. I thought about the add-ons that caused me trouble lately by breaking Adblock Plus (and often the browser as well) — .NET Framework Assistant, Skype Extension, Ask Toolbar (a.k.a. Zone Alarm Toolbar a.k.a. Foxit Toolbar). I noticed that they all have something in common: none of these extensions is being hosted on AMO, consequently none of them had to pass AMO’s review process. So while AMO’s review process still receives its fair amount of criticism and the AMO team continues to improve — apparently, it managed to achieve an important goal. The AMO editor team enforced good coding practices successfully enough to make conflicts between extensions hosted on AMO rare, it is mostly external extensions causing the trouble now. My congratulations to the editors and to the entire AMO team!

Tags:

Comment [8]

  1. Funtomas · 2009-11-24 11:57 · #

    That’s why I’m a bit skeptical about non-AMO hosting of addons announced recently.

  2. Brian King · 2009-11-24 17:23 · #

    Perhaps non-AMO hosted add-ons should be visually flagged in the Add-ons Manager? Worth suggested here:

    http://jboriss.wordpress.com/2009/11/23/redesigning-firefoxs-addons-manager/

  3. Dave Dash · 2009-11-24 17:44 · #

    One idea that I’ve been mulling over is an “extensions interaction database.”

    We’d analyze crash reports and find out the extensions that most often co-occur during crashes and see if we can learn something from that.

  4. MoJo · 2009-11-24 20:56 · #

    I think that lack of support from the Moz devs is a big problem for extension writers, and leads to nasty hacks in extensions.

    My own extension (Tabs Open Relative (Modified)) is a good example, I’m somewhat ashamed to say. It brings back functionality that Moz removed, and has proven quite popular. Thing is, I’m really just a user and found it easier to hack an extension up than to switch browser. I have little interest in maintaining it beyond the point where it stops working for me, so I don’t bother testing with with extensions other than those I run or with beta versions of FF.

    All that could be avoided if the devs just listened to the users and the extension developers. Unfortunately they just tend to ignore anything which does not fit with their own ideas of how FF should be, so we end up with a situation like this. Everyone is upset, no-one wants to spend the significant amount of time required to get a proper solution (assuming it is even possible) especially when the possibility of the developers breaking it with no consultation or discussion and no chance of a compromise is very real.

    Personally I am hoping that I will be able to port the extension to Chrome, or better still just add the feature directly to Chrome itself since they seem a lot better about accepting changes and requests for functionality. The AMO guys are doing pretty well, all things considered, but there needs to be a serious change of attitude from Mozilla if this situation is ever going to be fixed.

    Reply from Wladimir Palant:

    Looking at the description of your extension – I don’t remember Firefox ever having that feature built-in. Minefield has it however, so in Firefox 3.6 this should be the default.

    In general: while I can see how the current situation is frustrating for you, I doubt that Firefox developers are to blame. They need to see the bigger picture, in the end the product has to do well for millions of users. This also means that suggestions coming from single users can only be considered if there is indication that they will benefit everybody. This will be no different for Chrome, everybody has to make tough decisions about the user interface. The only alternative is implementing everything via options – and the result will be neither maintainable nor usable.

    I’m not convinced about “everybody is upset”. I think that the ones who are upset are a minority – and they will always be there, “one size fits all” doesn’t exist. That’s why extensions are there, to give these people a way to customize the user interface to their needs without having to change the core browser. There aren’t enough Firefox developers to maintain all user interface enhancements somebody might want.

    As to testing your extension with other extensions – this is usually not necessary, at least if you stick with good coding practices. AMO is enforcing just these coding practices, that’s what this blog post is about – there are usually no conflicts if all extensions do “the right thing”.

  5. tata · 2009-11-24 22:15 · #

    Is it possible to highlight the language specific lists after ABP installtion, so when i am in the usa, the usa one gets a bold font?

    Reply from Wladimir Palant:

    Yes, I’m planning to change that page so that choosing will be easier.

  6. MoJo · 2009-11-25 01:51 · #

    Thanks for replying, Wladimir. Sorry, I couldn’t see how to respond directly to your message.

    The issue I have is that half the add-ons and userChrome hacks I have are just to replace functionality that used to exist and was removed. My extension does just that. The ability to control how tabs from internal links and tabs from external links behave was removed in 3.5. There was a perfectly good, working and documented config option which was deleted.

    I can appreciate that the devs do need to consider the needs of the many over the needs of the few, but at the same time I can’t see any reason why they could not preserve this and other removed behaviour. It does not conflict with the new way things work, only supplements it. Worse still, when it was rolled out it actually broke the browser for everyone who had the preference set the way I describe, destroying their data by overwriting tabs. They didn’t even bother to test it or add code to fix/alert the user to the problem.

    There are huge quality issues with add-ons and FF in general, largely down to the hap-hazard nature of development.

    The whole thing is now a huge mess. The add-on system needs major fixes, particularly in terms of security. It could do with some real APIs too, instead of just relying on poking around in the browser directly. The FF codebase is also a complete mess and lack of documentation or even a reasonable way to compile the damn thing on Windows (and Linux isn’t that much better) makes it hard to contribute. If there were not so many barriers in the way I would have submitted a patch to fix the removed preference while still allowing the new slightly-different-but-basically-the-same-just-broken paradigm.

    If you look at the history of patches submitted to Chromium from outside of Google, it looks very positive in comparison to FF.

  7. dj · 2009-11-29 03:02 · #

    thanks so much for making this! im not very good with abp and i was still seeing a lot of ads. not anymore! thanks so much!

  8. Jordan · 2009-12-04 06:50 · #

    MoJo:
    I agree that Mozilla’s extension development has its faults, but I see that Chromium has a worse record of external contributions. They have had about twenty people take copyright ownership in their repo – that is twenty external contributions in well over a year. Taking a look through the changelogs that added those names, I see very few large changes; adding a link or making a tweak seem to be the most common. They are certainly less open on a UI basis, your extension’s functionality was submitted by a contributor and accepted.

Commenting is closed for this article.