Blair McBride [:Unfocused] (UNAVAILABLE) Reporter
	Description • 14 years ago

Given that various extensions use the old API interface, we should look into the possibility of providing a wrapper that allows use of the old API. 

The problem here being that the old API is all sync. It may be an acceptable compromise to have the wrapper block until the async calls of the new API complete (and have plenty of warnings in documentation about this effect).

	Dave Townsend [:mossop]
	Comment 1 • 14 years ago

I'm pretty wary of doing something like this. Unless we have very attentive add-on developers all this will do is defer the breakage to the point when we remove this temporary wrapper and I'm inclined to say that the sooner we break extensions the sooner they are likely to get fixed. If we removed this closer to b1 for example then that'd just be that many more extensions that didn't work in b1.

	Robert Strong (they/them - no direct email)
	Comment 2 • 14 years ago

^agreed w/ Dave

	Dave Townsend [:mossop]
	Comment 3 • 14 years ago

One option that might be a good idea would be to implement the basics of the old API, but make them non-functional and log errors to the error console whenever used. This would allow add-on developers to see quickly that something is broken and the error message could point them to a page explaining how to fix it. It would also make it easy for us to spot that an error users are seeing are likely due to an extension that hasn't been updated as opposed to a problem with the new code.

	Tanner M. Young [:tmyoung]
	Comment 5 • 14 years ago

(In reply to comment #3)
> One option that might be a good idea would be to implement the basics of the
> old API, but make them non-functional and log errors to the error console
> whenever used. This would allow add-on developers to see quickly that something
> is broken and the error message could point them to a page explaining how to
> fix it. It would also make it easy for us to spot that an error users are
> seeing are likely due to an extension that hasn't been updated as opposed to a
> problem with the new code.

I like this idea, but could have the the old API work and log errors.  My main concern is as a nightly tester: there are a large number of add-ons that used the old API (over 1,000 according to MXR), and after the rewrite was landed, my productivity came to a grinding halt, and I don't have the time to manually edit my installed extensions to use the new API.

I agree that we don't want to indefinitely defer the breakage, but if there is a more graceful way to break this, it could make the transition smoother.

Another concern (this one is from my ignorance of add-on writing), how will add-on developers handle backward compatibility for extensions that they want to work in both 3.6 and 3.7 but depend on the old API, would they have to branch their add-on on AMO, since the new interface does not work in previous versions?

	Tanner M. Young [:tmyoung]
	Comment 6 • 14 years ago

One other insane idea: for nightly testers, could we create an add-on or plug-in that acts as a wrapper for the old interface so that add-ons can still work for that user group?  Then, if an add-on developer doesn't have this extension/plug-in, they get log the warnings like Mossop suggests.

This makes the breakage immediate, but for users in the nightly testing category, they don't have to wait for the add-ons to be update or worse be forced not to update their browser at all.

	Dave Garrett
	Comment 7 • 14 years ago

Minefield is imbued with a name indicating that it is stated to blow up from time to time. Breakage of compatibility is not something to necessarily be fixed. If people need to use addons, then use a (more) stable version that is still supported.

A clean break of compatibility is best here. A series of warnings is an interesting idea, but I think the existing errors spit out are actually sufficient.

(In reply to comment #5)
> I don't have the time to manually
> edit my installed extensions to use the new API.

Don't even try. Not all conversions will be trivial. I'm in the process of getting Flagfox changed over and I have to rearrange the startup sequence a bit so I can load the location database file asynchronously. Even after that I have to tweak and test a few other parts because they expected sync and got async, thus creating a few race conditions. For addons that just fetch their version number it's simple, but for others that actually use the API it takes a bit more work.

> Another concern (this one is from my ignorance of add-on writing), how will
> add-on developers handle backward compatibility for extensions that they want
> to work in both 3.6 and 3.7 but depend on the old API, would they have to
> branch their add-on on AMO, since the new interface does not work in previous
> versions?

It's quite possible to support both at the same time. For example, to load a file:

if ("@mozilla.org/extensions/manager;1" in Components.classes)
{
  var ExtensionManager = Components.classes["@mozilla.org/extensions/manager;1"]
                         .getService(Components.interfaces.nsIExtensionManager);
  var file = ExtensionManager.getInstallLocation(id)
                             .getItemLocation(id);
  file.append(filename);
  continueWithFile(file);
}
else
{
  Components.utils.import("resource://gre/modules/AddonManager.jsm");
  AddonManager.getAddonByID(id, function(addon) {
    var url = addon.getResourceURL(filename);
    var uri = ioService.newURI(url,null,null);
    var file = uri.QueryInterface(Components.interfaces.nsIFileURL).file;
    continueWithFile(file);
  });
}

It just means that you're going to need to make everything using this have an asynchronous capable API using callbacks, even if in old Firefox versions it's going to actually be synchronous.

	Dave Townsend [:mossop]
	Comment 8 • 14 years ago

Going to call this a WONTFIX. I'd rather extension authors saw the breakage immediately rather than relying on them looking in the error console or anything.

I'm happy for someone to write a compatibility extension and I'll even take a look over it for sanity but it's not something we'll do in the platform.

It's not ideal for users but I think anything we do in the short term is going to harm the long term here.