Adblock Plus and (a little) more

How about making extension compatibility updates less annoying? · 2010-08-15 20:06 by Wladimir Palant

I came back from a vacation today and found around 20 mails in my inbox along the lines of “When will Adblock Plus be compatible with Firefox 4.0 Beta 3?” There are probably a dozen more questions in the forum which I didn’t check yet. Now I know of course that Adblock Plus is compatible with Firefox 4.0 Beta 3 because lots of people (yours truly included) regularly use Adblock Plus in nightly builds. So all I had to do was to log into AMO and change the compatibility info for Adblock Plus.

But this game repeats every few weeks whenever Firefox is nearing a release. And I cannot really prevent it because AMO won’t let me increase compatibility too early. So I have to be purely reactive here. And even when I’m not on vacation some users will always update their Firefox nightly before me. And some of them will mail me. And I will have to explain the same things again.

Is there really no better way? Something to save my users from this annoying experience? I could for example imagine AMO allowing to increase compatibility a few days before Firefox development branches so extension developers who are testing their extensions with nightly builds get a chance to update their compatibility info in time. And also give developers a way to see when the allowed maxVersion changes, via RSS feed or something like that. There is probably already a better way than monitoring https://addons.mozilla.org/pages/appversions for changes but I am not aware of it. Sure, extensions keeping up with nightly builds is neither common nor recommended but are these suggestions reasonable? Or maybe there is a different solution?

Tags:

Comment [20]

  1. Ferdinand · 2010-08-15 20:37 · #

    Can’t adblock be converted to a jetpack extension?

    Reply from Wladimir Palant:

    Probably, with some (significant) effort. But it won’t solve any problems.

  2. flod · 2010-08-15 21:00 · #

    I was going to ask the same question…

    The problem, for example, is that the 4.0b4pre maxversion was enabled several hours after the nightly builds switched from 4.0b3pre to 4.0b4pre, and that’s quite absurd: if my extension was compatible with the last 4.0b3pre nightly, it will compatible also with the first 4.0b4pre build, so you could enable that compatibility at least 24 hours before the switch in the build system.

    P.S. You can subscribe to the “Recent activity” feed in your Developer Hub.

    Reply from Wladimir Palant:

    I’m not sure how “Recent activity” feed can help me – I can only see tons of messages about my extensions being added to collections. Maybe somewhere deep down there are also messages about allowed maxVersion changes but I have no chance of finding them.

  3. Mike · 2010-08-15 21:00 · #

    Firefox should have user-visible button to ignore version check for specific addon (hello, new addon-UI!). In 99% cases this button will work.

    Reply from Wladimir Palant:

    No, definitely not. As Gijs sums up nicely below, a “Shoot me in the foot” button is never a solution to anything. The whole point of compatibility info in extensions was to take a decision away from users that they are usually not qualified making and where they have no chance of knowing the consequences.

  4. Gijs · 2010-08-15 21:26 · #

    Wladimir: yeah, I’d really like there to be an option ‘nightly’ in maxversion (on AMO), that AMO takes care of updating. Goodness knows I see the same pattern for other add-ons (less popular perhaps, but still!) – sometimes even with bugzilla bugs filed about it…

    Mike: No. Adding grandma-friendly buttons for things that do un-grandma-friendly things is not a good idea.

  5. Clochix · 2010-08-15 22:29 · #

    Maybe people wanting to try nightlies builds and use theirs favorites extensions should be encouraged to use Add-on Compatibility Reporter . It prevent from being annoyed with compatibility checks.

    Reply from Wladimir Palant:

    I have thousands of nightly users – encouraging them to do anything one at a time isn’t a good use of my time :-(

  6. bernd · 2010-08-16 00:40 · #

    Did you fix bug 584759 before updating amo?

    Reply from Wladimir Palant:

    No, I am looking into fixing this now. It doesn’t affect Beta 3 however, only the most recent nightlies.

  7. Dave Townsend · 2010-08-16 02:47 · #

    AMO could add the new max version when we freeze for a new beta, that is normally nearly a week in advance of the beta release. I’ve also suggested a couple of times in the past that AMO could just email all extension developers who have an add-on marked as compatiblity with the newest nightly builds whenever a new max version gets added.

    Reply from Wladimir Palant:

    Yes, an email in advance would be perfect – but I would already be happy if there were some solution for extension authors who get active on their own.

  8. Tony Mechelynck · 2010-08-16 04:01 · #

    In lieu of RSS feed: you might try watching addons.mozilla.org::Administration <administration@add-ons.bugs> on Bugzilla to get bugmail when a new version gets requested by some application team (like recently bug 587514 for new SeaMonkey versions) but it’ll likely also spam your bugmailbox with a lot of unrelated stuff. Sorry, I don’t have any better idea.

    Reply from Wladimir Palant:

    This was my thought as well – but I didn’t find any bug related to the recent bump of Firefox maxVersion. I’m not sure how things work at AMO these days but apparently most version range changes are implemented without creating a bug. Which makes me assume that there is a process in place that no longer requires a third party to nag AMO developers – and that this process can be improved.

  9. Minh Nguyễn · 2010-08-16 04:22 · #

    The Developer Hub has a Recent Activity page that indicates when a new version is added. It has a feed too.

    Reply from Wladimir Palant:

    I’m not sure how “Recent activity” feed can help me – I can only see tons of messages about my extensions being added to collections. Maybe somewhere deep down there are also messages about allowed maxVersion changes but I have no chance of finding them.

  10. Jim · 2010-08-16 06:50 · #

    Now I know of course that Adblock Plus is compatible with Firefox 4.0 Beta 3 because lots of people (yours truly included) regularly use Adblock Plus in nightly builds.

    Well, I’m not sure Adblock Plus does in fact work in the nightlies at the moment. I’m running Minefield on Linux x86_64 (Gecko/20100815 Minefield/4.0b4pre) and I find that if I now have Adblock Plus enabled redirections stop working. So going to http://www.google.com tries to redirect me to http://www.google.com.au and that works with AdBlock Plus disabled. With Adblock Plus enabled I go to http://www.google.com and all I get is a 302 status page.

    Reply from Wladimir Palant:

    Yes, redirect API changed, so much about “no major changes expected after Beta 3” :)

    I’m at it right now, this should be fixed in development builds tomorrow. I’ll also make sure to release Adblock Plus 1.2.2 before Beta 4 is out.

  11. macel · 2010-08-16 08:40 · #

    Yeah, this time the change from async redirect API actually broke Adblock (https://bugzilla.mozilla.org/show_bug.cgi?id=546606#c98) :)

    Another new issue (at least I think so) is the following error:

    Error: invalid ‘instanceof’ operand Ci.nsIDOMNSHTMLAnchorElement
    Source File: file:///…/extensions/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D/modules/AppIntegration.jsm
    Line: 655

    It happens when you right click some sites, e.g. gmail or http://forums.mozillazine.org, you will also see out of place context menu items from adblock on these sites.

    Reply from Wladimir Palant:

    Thanks for pointing me to the relevant bug, so much about “no major changes expected after Beta 3” :)

    I’m at it right now, this should be fixed in development builds tomorrow. I’ll also make sure to release Adblock Plus 1.2.2 before Beta 4 is out.

  12. flod · 2010-08-16 10:30 · #

    @wladimir
    I didn’t take into account the amount of activity you have on ABP ;-)

    Maybe you could open an enhancement bug on AMO to expose only that information on a feed (it shouldn’t be so difficult, since it’s already published in the Recent activity).

    Reply from Wladimir Palant:

    Ok, now I can see them – if I take the messages of one extension only (e.g. JavaScript Deobfuscator). Type is versions_compat_add but none of the currently defined filters allow to filter “system messages”. Yes, clearly an AMO bug.

  13. Ami Ganguli · 2010-08-16 11:06 · #

    I think the “right” answer is to handle this within Firefox, not foist it upon all the extension authors. Beta builds should be more more lenient in version-checking: allow extensions to work even if they’re one beta behind.

    This gives both users and extension developers a break, at the risk of occasional bugs due to API changes. But early beta-testers should expect occasional breakage. For release candidates, change the rules to only accept extensions that claim compatibility with the final release.

    (if there are indeed major API changes and most extensions really wouldn’t work, then an exception could be made for that particular beta)

  14. Laurens Holst · 2010-08-16 22:20 · #

    Indeed I’d say the Add-on Compatibility Reporter is the answer you should give to those questions (and advertise it prominently with the download so you don’t have to manually inform every one of them)…

    It works marvellously, and even provides users the ability to easily provide feedback which I’m assuming is shown to the addon developer. Very nice.

  15. BenoitRen · 2010-08-16 22:41 · #

    This is one of the biggest reasons that I didn’t like toolkit’s extension compatibility system infecting SeaMonkey. It’s obvious that not much thought went into it when designing it.

    In this case, people are using nightly builds. Things breaking is to be expected in the first place, so compatibility checking is out of place.

  16. johnjbarton · 2010-08-17 09:11 · #

    Firebug provides a separate alpha download for FF4 with max version set to allow install in all 4.0 versions. We don’t change the max version on the stable version. That way we don’t have any of these problems. But then again, so far FF4.0 hasn’t been usable with Firebug anyway, nothing we can do about that.

    The real fix for all of these problems is for Mozilla to test Firefox with extensions installed. They have an impressive test suite, all they have to do is fire it up with a hundred or so extensions. Then they can tell users and extension authors which addons are compatible, all automatically. The other way around is just silly.

  17. EP · 2010-08-17 20:28 · #

    “I’m at it right now, this should be fixed in development builds tomorrow. I’ll also make sure to release Adblock Plus 1.2.2 before Beta 4 is out.”

    Which Firefox 4.0 Beta 4 could be due out on August 23 as noted here.

    And be sure to update ABP compatibility with the new Seamonkey 2.1b1pre nightly builds as Seamonkey 2.1 alpha 3 will also be released around the time Firefox 4.0 beta 4 comes out.

    Reply from Wladimir Palant:

    I am almost ready to release Adblock Plus 1.2.2. If I don’t get it done today I’ll for sure do it tomorrow.

    As to SeaMonkey – thanks for the hint, I see that AMO already added 2.1b1 as allowed SeaMonkey version. Will mark compatible with it then.

  18. Jeff Balogh · 2010-08-17 22:59 · #

    This adds a feed to the appversions page: bug 588120.

    AMO adds a new app version when someone files a bug about it, which is still pretty lame. The Firefox release driver (legneato) is working on a better system for distributing updates.

    Reply from Wladimir Palant:

    Thank you very much, looking forward to seeing that change in production.

    I didn’t have to file bugs about adding new versions lately so I simply assumed that there were already a better system. Anyway, I hope some solution will be found here as well.

  19. skierpage · 2010-08-18 03:48 · #

    You suffer these slings and arrows for the benefit of multitudes, yet you won’t put out a tip jar to allow small tokens of our appreciation.

    I had a briefcase full of money for you , but I understand you’re skipping the money stage and aiming for sainthood. :-)

  20. Brian Gaff · 2010-08-20 22:27 · #

    Well, I had not realised till I read this that the compatability issue was mostly not true. Seems to me though that anyone running betas are actually running software that is only provisional, so maybe it should have more relaxed attitudes to third party add onse.

    I am a blind user, and there are actually some nasty things that Firefox hides away that cause it to fall over if used with nvda, for example, so there is a way to go yet to get it all working properly, but one of those is not your add on. Brian

Commenting is closed for this article.