Firefox 3.1 - How to update your extensions

[paul.rouget]

It's time to update your add-ons !
Firefox 3.1 beta2 will likely be released the first week of december.
This release will be stable enough for updating your add-ons.

This thread is where you can ask for help about issues you might
run into when updating your extensions to Firefox 3.1.

Most add-ons will not require changes in order to support Firefox 3.1
as really few interfaces has been updated.

Here a list of identified issues you might run into :
https://developer.mozilla.org/En/Updating_extensions_for_Firefox_3.1

You may be interested on some new features shipped on Firefox 3.1 :
https://developer.mozilla.org/en/Firefox_3.1_for_developers

Should you have any questions to ask or feedback to give, please do it
below, we'll do our best to help.

[Alfred Kayser]

Can you make sure that the 3.1b3 tag is added to AMO well in advance before actually pushing 3.1b3 to the people,
so that we really get a chance to upload updated versions and get these reviewed before the 3.1b3 release is pushed?
Or, even better start to allow 3.1 tag from now on, so that we really can get prepared for the big update.

[paul.rouget]

Ok, let we see that with the team.

[Philip Chee]

dev-doc-needed, relnote

Bug 467045 - Custom Buttons2 extension broken after Bug 407725

Bug 407725 - Toolbar customisation pointlessly removes, clones and adopts nodes

------- Comment #3 From Gavin Sharp 2008-11-27 19:08:17 PST (-) [reply] -------

The fundamental change from bug 407725 is that toolbar items are no longer
cloned from the palette, and are instead moved from the palette to the toolbar.

------- Comment #5 From Philip Chee 2008-11-28 00:04:30 PST (-) [reply] -------

> The fundamental change from bug 407725 is that toolbar items are no longer
> cloned from the palette, and are instead moved from the palette to the toolbar.

When Custom Buttons2 saves its settings, it looks through the .palette
(gToolbox.palette.childNodes) for any custom buttons defined. If some or all of
the buttons are on a toolbar, the code doesn't find these and when their
overlay.xul is created it doesn't contain any of the buttons that are active on
a toolbar.

It's just a SMOP to look at the nodes in the toolbars as well e.g.

Code: Select all

var buts=gToolbox.getElementsByAttribute("id", "*")
for (var j=0;j<buts.length;j++){
  var but=buts[j];
  if (but.getAttribute("id").indexOf("custombuttons-button")!=-1){     // Our Kind of button
  .....etc....
  }
}

Plus, they'll have to filter for duplicates for Gecko < 1.9.1b2

[mctones]

As Alfred requests, it would help us devs out a lot if you were able to allow an AMO update tag that is greater than the current release. That way we don't have the gold rush everytime there is a release, with devs having to (more often that not) just change one string in the install.rdf and AMO Editors having a huge queue.

As an example, my addon has had b2pre for a while now and I strongly suspect that the official release of b2 will not break my addon. People who download the beta2 on day 1 will not be able to use my addon until it passes through AMO as AMO still restricts to b2pre. If you allow me to change this today and something is broken in b2, what's the difference? In both cases early adopters cannot use my addon in b2 for the first few days.

I can appreciate that an AMO editor does not want to pass fit an addon marked 3.1.0.* when no such release exists for them to test it, but I feel this really does not matter. Most developers are active users of their addon, and if not then they at least have a number of active users who are quick to let them know if something was wrong. If I was to pass my addon as fit for 3.1.0.* now, as soon as this official release hits us it would become apparent straight away if something was wrong. A few hours work and the next release would be at AMO before that day is out. As said above, the net result is the same, people who are the first to download a Firefox release do not have access to the addons.

What AMO Editors need to ask themselves is what is harder for them: dealing with hundreds of addons in a queue around time of a Firefox update or dealing with a handful of addons that passed themselves as fit for 3.1 and now sit in the queue after a hasty fix.

Who suffers most with a main 3.1.0.* release tag being available today: a few isolated users for a short time after release if something slipped through the net in a few addons.

Who suffers most with the current setup: everyone, from AMO editors having a long queue at release time, users who download the beta or full release ahead of others and have to wait for the AMO update to pass through, or developers who have to clockwatch all the time to change one max version string and nothing else between 3.1.a1pre and 3.1

If a full 3.1.0.* is a bit too much for AMO to swallow, for the next release at least give us 3.2.b9999 from the start so we don't have to endure the release-amend max version-release-amend max version-release etc nightmare.

Cheers, Tony

[BenoitRen]

3.1.0.* is useless; there are only three version numbers since Firefox 3.0. You'd want 3.1.*.

[sewqyne]

What am I to use know for maxversion rdf tag? 3.1.* or what?

[BenoitRen]

AMO doesn't allow version schemes with asterisks.

[Alfred Kayser]

Let's start with just updating AMO with the upcoming maxVersion before it is actually released.
So, when preparing to launch 3.1b2, allow extension owners, especially themers to update their extension to the coming release.
And, as the promise of 3.1b2 is that there will be no changes with impact on extensions, AMO could start be allowing 3.1 as maxVersion from 3.1b2 on.

Note that for themes this problem is more critical, as it forces users to switch back to the default theme when upgrading FF and the theme is not upgraded yet, and a lot of users will be disappointed and don't come back to the previously selected theme (I have the emails to prove this).

[mctones]

What am I to use know for maxversion rdf tag? 3.1.* or what?

No, developers can only use that tag once 3.1 has been released to the general public.

AMO doesn't allow version schemes with asterisks.

You sure about that? I have had asterisks in my addon for a long time.
---
I am also not too sure who AMO are trying to protect either - surely the majority of people who download pre releases understand that things may not work (includng themes and addons), and lets be honest a few probably have max version checking turned off in Firefox and on AMO anyway.

[BenoitRen]

Maybe not asterisks themselves are banned, but I'm sure that a scheme like 2.0.0.* was banned from usage.

[Shadoefax]

Bug 458898 - Windows opened via openDialog function aren't visible in Firefox 3.1b1pre

This bug breaks my FEBE extension. This will be fixed by the time 3.1 goes public, right?

[fligtar]

That way we don't have the gold rush everytime there is a release, with devs having to (more often that not) just change one string in the install.rdf and AMO Editors having a huge queue.

If all a developer has to do is bump the version number in install.rdf, they should not upload their new add-on to the queue. Instead, just changing the maxVersion in the Developer Tools area for the latest version will allow the extension to work properly in the future, as Firefox checks AMO for compatibility information.

Maybe not asterisks themselves are banned, but I'm sure that a scheme like 2.0.0.* was banned from usage.

Asterisks are only banned in minVersions, but have always been allowed in maxVersions. In fact, they are the recommended version to use (2.0.0.* for Firefox 2 add-ons and 3.0.* for Firefox 3 add-ons, and 3.1.* will be for Firefox 3.1 add-ons)

The AMO policy of not adding a version until it's actually possible that someone has tested their add-on in that version has been around for a long time, and we still have people that don't test their add-ons in that version but go ahead and mark compatibility anyway. I will start a discussion on revising the policy in mozilla.dev.amo and solicit feedback from the Firefox, Add-ons Manager, and AMO teams there.

[mctones]

If all a developer has to do is bump the version number in install.rdf, they should not upload their new add-on to the queue. Instead, just changing the maxVersion in the Developer Tools area for the latest version will allow the extension to work properly in the future, as Firefox checks AMO for compatibility information.

Can you clarify this statement please - this reads that if my addon has maxVersion set to 3.0.* in the install rdf, but I change the AMO setting to 3.1b3pre then AMO overides the local install process of Firefox checking the install.rdf and an extension will install OK?

[mctones]

The AMO policy of not adding a version until it's actually possible that someone has tested their add-on in that version has been around for a long time, and we still have people that don't test their add-ons in that version but go ahead and mark compatibility anyway.

Yes, and I can supply a whole lot of emails from AMO editors who have tested and passed fit my addon updates, with their decision based on them using a version less than that set in the maxVersion, so I guess the whole thing needs rethinking.