About upgrading a profile to Web-Extensions

Add-ons Development
#1

When uploading a web-extensionified version of my add-on, I get the following message:

We allow and encourage an upgrade but you cannot reverse this process. Once your users have the WebExtension installed, they will not be able to install a legacy add-on.

What consequences does this have exactly?
Since the conversion to web-extension crippled my add-on extensively, I want my users to be able to go back to the old version in case they keep using an older firefox version. Will this be possible?
Sounds like the add-on profile on AMO will be converted, I.E. all non-web-extension versions will be lost.

So do I have to create a separate profile for the web-extension version?

On a sidenote, there was also a warning, that I can’t use the firefox-specific way to mark it an alpha version by using version “5.0a”. How do I now say that it’s an alpha version?

#2

Your users will be automatically updated to the latest version, which will be your webext. You, as the dev, cannot upload a non-webxt again to that listing. However your users can freely downgrade their version, they just have to make sure to turn of auto updates, otherwise it will keep updating them to the webext.

I’m not sure about this one, hopefully someone else can answer. I thought appending a or b does offer to go through to the beta channel.

1 Like
You cannot update a WebExtensions add-on with a legacy add-on
#3

I can’t use the firefox-specific way to mark it an alpha

If you mean this

Screenshot - Feb 13, 2017 1.18 PM.png1220×236 12.3 KB

then you very much can do that, it is only telling you that you won’t be able to load the same file int Chrome, for example, since Chrome requires the version to be up to 4 numbers separated by .s, and notching else.

2 Likes
#4

[quote=“noitidart, post:2, topic:13585”]
You, as the dev, cannot upload a non-webxt again to that listing.
[/quote]That’s significant - and potentially problematic.

I have developed a webextension version of an SDK addon, but it only works with Firefox desktop because the fennec APIs are not available yet. My plan was to release the webextension - flagged ‘desktop only’ - for Fx53, say, leaving Android users on the SDK version. But it I do that would it mean I could not then release an Android-only SDK version, to fix a problem?

If that’s true I must not release a webextension until the APIs I need are released for fennec.

2 Likes
#5

the fennec APIs are not available yet. […] for Fx53

In case the API you are missing is browser.tabs, that works in Fennec 54 (I have tested it, and it does :slight_smile: ).

#6

Thanks for the info.

Where did you see the .s information? Does the .s stand for snapshot, i.e. could be used to flag for alpha/beta?

I found this information: https://developer.chrome.com/extensions/manifest/version
which says you can use the version_name property for beta names & such… (tho there doesn’t seem to be a beta-channel for chrome)
I wonder if AMO supports this as well.

#7

If you try to temporary load an extension in chrome that has a version that doesn’t comply with this, chrome will tell you so.

"version_name can be set to a descriptive version string and will be used for display purposes if present."
Sounds like version_name is not really good for anything other than confusing people by displaying a version that is not actually the real version -.-

#8

[quote=“NilkasG, post:5, topic:13585”]
In case the API you are missing is browser.tabs…
[/quote]No - options_ui - <a href=https://bugzilla.mozilla.org/show_bug.cgi?id=1302504>bug 1302504

I was monitoring browser.tabs too :wink: - <a href=https://bugzilla.mozilla.org/show_bug.cgi?id=1260548>bug 1260548

#9

Yeah, the lack of that is quite annoying. And especially stupid. I mean, all it would take is a single button to open a new tab. That could literally be done in a single line of code.

#10

[quote=“NilkasG, post:9, topic:13585”]
Yeah, the lack of that is quite annoying
[/quote]Particularly because of this: https://discourse.mozilla-community.org/t/prefs-do-not-show-on-fx-51-for-android/13471

1 Like
#11

I have just ran into this problem on Thunderbird. I released 2 versions for quickFilters last week, to both support my ESR (Tb60) users and those who run daily (Tb68). The builds are necessarily different. Someone reported a bug on the legacy version and now I cannot upload my fix! That’s very bad because I have a bunch of licensed users who expect support and up-todate versions for the ESR.

#12

There’s a TB addons category for discourse, you might be better off posting there.

This problem was predicted in this post
https://groups.google.com/forum/m/#!topic/tb-planning/XUU-G9PMhi8
I haven’t seen anything about it since.