Updating the add-on for compatibility with Firefox 4.0, but trying to keep it compatible with 3.x. Advice?

I have an add-in written for Firefox 3.6, and now I am updating it for Firefox 4.0, trying to also maintain its compatibility with 3.6. Does anyone have experience trying to do this, or tips on how to do this, without code that gets too spaghetti-ish?

There are several places where its compatibility with both versions means doing something like this:

.myAddonClass { -moz-background-size: 100% 100%; /* Fx 3.x */ background-size: 100% 100%; /* Fx 4.x */ } 

which generates a CSS warning in both versions. I can live with it. There are other places where I do things like this:

 /** get the current version of this addon */ function getVersion() { var version; if (Application.extensions) { // Fx 3.x version = Application.extensions.get(' myaddon@example.com ').version; } else { // Fx 4.x Components.utils.import('resource://gre/modules/AddonManager.jsm'); AddonManager.getAddonByID(' myaddon@example.com ', function(addon) { version = addon.version; }); sleepUntil(function() { return version; } } return version; } 

(where sleepUntil is a utility function that uses the Thread.processNextEvent method)

Checking if Application.extensions defined seems cleaner than just checking the Application.version string, but maybe there are some flaws in this approach that I don't know about?

I am also having problems pasting content into web pages. In one case, doc.body.appendChild worked in 3.x but not 4.x, so I tried to do this:

 try { // Fx 3.x doc.body.appendChild(myElement); } catch (e) { // Fx 4.x let span = doc.createElement('span'); doc.body.appendChild(span); span.innerHTML = outerHTML(myElement); } 

The code above does not work, but if I insert throw new Error('') immediately before doc.body.appendChild(myElement) , then it works, indicating that in Firefox 4, calling appendChild seems to somehow modify myElement gives an error message. I'm sure I can figure out how to make this piece of code work, but I'm worried that I will have a lot of problems too, so I want to see if anyone else has gone through a similar process, and I have all the tips about which I need to know.

Sorry for the long question. Here is what I really ask:

  • What advice do you have in order to simultaneously support an addon compatible with both Firefox 3 and Firefox 4?
  • What do you think of the idea of ​​branching the code so that we have one version for 3.x and another for 4.x? Then we had to apply any new features to both versions and test them in both versions, etc.
  • In general, it is better to check for a specific function (for example, I did with if (Application.extensions) ... or try / catch) or just check if Application.version starts with '3' or '4'?
+4
source share
2 answers

What is your advice on trying to keep the addon compatible with Firefox 3 and Firefox 4 at the same time?

I would recommend one XPI for the last two major versions. People with older versions are a lost case, and having two XPIs for different "active" versions is confusing (I have not experimented recently with how AMO presents this, but this is my old impression).

What do you think of the idea of ​​branching the code so that we have one version for 3.x and another for 4.x? Then we had to apply any new features to both versions and test them in both versions, etc.

I would only do this if the code became too spaghetti. As an amateur, I stop updating the old version, leaving it to people using older versions of Firefox. You can view the statistics of your extension on AMO to check the speed of adoption of new versions of Firefox (even if the statistics page is not very easy to use.)

In general, it is better to check for a specific function (for example, I did with if (Application.extensions) ... or try / catch) or just check if Application.version starts with '3' or '4'?

Capability-based forking does not matter, since you are dealing with a fixed set of host applications, unlike web pages.

Be aware of potential side effects:

  • Checking the version of the application will make it difficult to port to other applications, so if parts of your code use only the functions of the platform and not the functions of a specific application, it would be more reasonable to test the version of the platform.
  • try..catch can also catch other errors not related to the one you expect. I would avoid that.

PS

1) To avoid CSS warnings about unknown properties (if there are many), you can use different styles for different versions using appversion in chrome.manifest

2) I believe that the Thread.processNextEvent method is dangerous, since it prevents the call stack from being unlocked until you finish.

+1
source

One of the Mozilla #addons IRC channel suggestions for my getVersion() function is to write an AddonManager layout that is supported by nsIExtensionManager. Or use this one . Thus, the function itself should not have this if / then pattern.

+1
source

Source: https://habr.com/ru/post/1332555/


All Articles