Scott is out on vacation, so I’m noting these down in the spreadsheet in his absence! The reason why we’re doing it this way is because programming for the recommendations will be done manually. So compiling them from suggestions we’re getting from various sources into one document will help us organize them and not miss anything. We’ll see how it works in the next few weeks, and can make adjustments to the process if it doesn’t work well.
I’m not a developer. Apologies if I’ve missed or misunderstood something.
Some developers may be in the process of porting their extensions. My understanding is that in order to port their addon’s data from legacy to webextension they will need to be hybrid for at least one version [of their addon].
Doesn’t this mean that in most legacy-to-webextension situations the developer is likely to hold off switching to a full webextension version until the last possible moment (the end of 56) to ensure that as many of their users are updated?
Perhaps it would be good to get a good poll of developers who intend to port for 57. Notably this would prevent us from recommending webextensions for them.
Or at least, deprioritize finding (or creating?) alternatives (in case they didn’t come through in time).
The process would be exactly the same if they did it in FF50
They dont have to wait for FF56 to change over. In fact it is better to do it sooner to iron out issues.
Unless, they are waiting for an API that is not currently available.
Add-ons that store custom data and need to migrate it are probably in the minority.
Some may do that, but they also need to balance it with their users complaining about a WebExtensions version, and the add-on potentially breaking because of the compatibility changes happening in 55 and 56. There’s a statistics dashboard where developers can see the popularity of different versions, which should give them a good idea of user migration.
We have a very good idea of who is or isn’t migrating, at least among the top add-ons. Since these lists are hand-curated, there’s only so much we can do for the long tail.
Obviously I’m the developer of
Q: I’m also maintaining another extension which is not a complete WebExtension yet (b/c it contains a settings migration shim). Will AMO start suggestings “alternatives” for this until we upload a version without the shim?
@Caspy7: From a developers perspective I can tell you that, at least our users, were OK with us keeping the shim around however long we want, as long as we make sure that we push the update (without the shim) in time before 57 finds its way onto their devices.
Recommended alternatives at
– closed on 2017-07-13, verified fixed 2017-07-21.
@eviljeff please, when might we begin to see recommendations?
We’ll start adding recommendations soon. After that, it needs to be enabled in the Add-ons Manager, which is up to the Firefox team, but should also happen soon thereafter.
Thanks; cross reference https://blog.mozilla.org/addons/2017/08/10/upcoming-changes-compatibility/#comment-224134 under today’s Upcoming Changes in Compatibility Features | Mozilla Add-ons Blog
The WebExtension version will be released in a few days. So there is no need to suggest alternatives to New Tab Override because the WebExtension will be available very soon.
In a few days = today
I uploaded the update to AMO a few minutes ago. Now waiting for review.
Here you can find more information:
Nice! I cannot see v7. You can provide an unlisted signed version with another UUID for power users like me that want to test it out That is if it takes too long to review.
If I ever want a feature I will contribute to your extension instead of maintaining mine.
You can find an unsigned version here:
You have to use about:debugging to load it temporarily or you have to use a pre-release version of Firefox and to disable the signature to test it. I don’t want to create a unlisted version with another ID because I hope the review won’t take too much time.
It would be great to see contributions, I accept pull requests!
(I am coauthor of both)
(xStyle is based on the Chrome version of Stylish)
Legacy: SixOrNot, IPvFox provide IP addresses of servers accessed for building current page. SixOrNot (and maybe IPvFox?) also changes its toolbar icon to 4 or 6 to indicate if the top-level file of the page is connecting via IPv4 or IPv6.
Possible WebExtensions replacement: Show Server IP
Legacy: various host names in Title. This allows applications that need the server name for matching with site-specific logon credentials, such as for KeePass.
WebExtensions: Hostname in Title (There are probably others, too, but this was the first one I found.)