Spun off from https://github.com/MrAlex94/Waterfox/commit/33912818661edfbc9d02e23fc82fabde7f290e40#commitcomment-28209247
I guess that we also need attention to:
extensions.update.background.url– and maybe more importantly,
extensions.update.urlI guess that we also need attention to:
extensions.update.background.url– and maybe more importantly,
extensions.update.url
Checking Browser Console with Net/XHR enabled, those requests params look ok. And the Add-ons Manager is not offering me incompatible updates.
What part of those needs attention?
… the Add-ons Manager is not offering me incompatible updates. …
So if (for example) you install Conex 0.0.78, then about:addons can find and install:
– yes? (Do I understand correctly?)
So if (for example) you install Conex 0.0.78
I can't. Waterfox says "Conex could not be installed because it is not compatible with Waterfox 56.0.4." (I'm testing on a self build from https://github.com/MrAlex94/Waterfox/commit/77516ffcc915ad669505f014cfa0092a32c4aa89 , the only difference with 56.1 is the Waterfox version number).
This behavior is correct. Waterfox should refuse to install it (unless Waterfox does support all of the WebExtensions APIs introduced in Firefox 57, but I never got an answer when I asked about this, and I didn't notice any commits that looked related, so I assume not).
What's wrong is, your AMO link is offering me the "Add to Firefox" button. Instead, it should say, "This add-on is not compatible with your version of Firefox."
This is purely a UA issue. This is not an add-on compatibility issue.
Clear now? :)
Sorry, I'm slowly adding and testing the APIs in 57. I figured for now, some add-ons work; so best to make it not look like Waterfox doesn't support anything.
… Clear now? :)
Yes and no :)
From the commit:
… Pretend we're 57.0 …, so add-ons install properly on the Mozilla AMO. …
– and from yesterday's https://github.com/MrAlex94/Waterfox/issues/413#issuecomment-375037787:
… Firefox 56 is just as "Quantum" as 57, bar bug fixes and various features being explicitly enabled. …
If Waterfox 56.1 is to be treated as if it's Firefox 57 for add-on services e.g. AMO, then (yes) https://addons.mozilla.org/addon/conex/versions/?page=2#version-0.0.78 _should_ offer:
– and (this comment crossing paths with https://github.com/MrAlex94/Waterfox/issues/484#issuecomment-375479476 above) release notes should might explain that _not every_ extension for Firefox 57 will work faultlessly with Waterfox 56.1 (or words to that effect).
… I'm not sure what to do here, I'll see if it's worth implementing the archive store and using that for the older add-ons 🤔 as a replacement to the add-ons manager?
If the the add-ons manager will be limited to the archive in its current state, then the update capabilities of the manager will be unable to wholly fulfil the expectations of users who choose to install extensions for 57. (Some of those people will expect an automated, user-friendly way of discovering updates; not requiring periodic visits to the AMO page of each such extension.)
Kicking the ball around … for now (for 56.1.0) maybe have:
a) about:addons working with AMO and
b) complementary use of the archive store (not integrated with about:addons).
All things considered, I'd happily accept a Download anyway button for any legacy add-on that's found in the archive. That's an oversimplification :-) 'cause I don't want this comment to be any longer than it already is …
@grahamperrin Quantum is not mainly about extensions. The Quantum-ness of the browser is irrelevant.
@MrAlex94
I'm slowly adding and testing the APIs in 57.
Nice! Thanks for the answer.
for now, some add-ons work; so best to make it not look like Waterfox doesn't support anything.
I agree. Unfortunately, for the reasons noted, bumping the UA version to 57 has the opposite effect.
In my experience, AMO works well with a Firefox 56.0 user-agent. It allows installing legacy extensions and most WebExtensions. I haven't seen a lot of grayed out "Add to Firefox" buttons. And AMO doesn't allow installing Waterfox-incompatible extensions. The resulting impression is that Waterfox is compatible with most extensions, including legacy extensions.
So perhaps would be best use a Firefox 56.0 UA for AMO until Waterfox actually supports the WebExtensions APIs introduced in 57?
… Quantum is not mainly about extensions. …
Understood, thanks, note the quotation marks within the quote :-)
Fixed in https://github.com/MrAlex94/Waterfox/commit/22dcd9a96ef94eb43868b2c33e8ec8e3aece0f2f . Many thanks! :smiley:
If I understand correctly, the commit will:
– checks for updates will not find updates to extensions that require 57, if those extensions were installed from addons.mozilla.org.
I'll await release notes before any change to the title of this issue.
https://mozilla.logbot.info/amo/20180322#c14502837
Greetings from Waterfox land. If anyone with AMO expertise can help us with https://github.com/MrAlex94/Waterfox/issues/484 I'll be hugely grateful.
https://mozilla.logbot.info/amo/20180331#c14543912
I'd like to (experimentally) have Waterfox 56.1.0 treated as if it's Firefox 57.0.4 for add-on update purposes. Changes to
extensions.update.urlseem to not have the required effect. Do I need to change any other preference?
… no answer yet, I'll try to catch someone there during a weekday.
I'd like to (experimentally) have Waterfox 56.1.0 treated as if it's Firefox 57.0.4 for add-on update purposes. Changes to
extensions.update.urlseem to not have the required effect. Do I need to change any other preference?
You also need to change extensions.update.background.url. That will make AMO treat Waterfox as Firefox 57.0.4 for add-on updates. But Waterfox doesn't offer the updates for 57. I think Waterfox is internally comparing its own appversion with the update manifest, instead of using 57.0.4.
Thanks,
You also need to change
extensions.update.background.url. …
Hmm, I certainly did change both preferences at one point during the last round of experiments (before my second post to the #amo channel), but still didn't get a listing for the required update in response to a manual check.
The two defaults, with 56.1.0_2 on FreeBSD-CURRENT:
extensions.update.urlhttps://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=%APP_VERSION%&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%¤tAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE%
extensions.update.background.urlhttps://versioncheck-bg.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=%APP_VERSION%&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%¤tAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE%
For the first value, not the second, I typically change %APP_OS% to Linux (to work around a separate issue) – that's enough for me to get, from AMO, the updates that are appropriate for 56.x.
56.x aside:
I already tried the obvious, 57.0 (and 57.0.4) in lieu of %APP_VERSION% and %CURRENT_APP_VERSION%. Also normal in lieu of %COMPATIBILITY_MODE%. And so on.
Maybe I should also disable sending the referer header? (I have Referrer Switch, but don't expect it to work in this context.)
what part of the string should I change, for a manual check at about:addons to get updates to extensions that require 57.x?
Maybe I wasn't quite clear. Changing those prefs is not enough to see the updates in about:addons.
If you open an AMO update URL in a tab, you'll notice that AMO does offer the update for 57.
https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=2&id={73a6fe31-595d-460b-a920-fcc0f8843232}&version=5.1.5&maxAppVersion=*&status=userEnabled&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=57.0.4&appOS=Linux&appABI=x86_64-gcc3&locale=chrome://global/locale/intl.properties¤tAppVersion=57.0.4&updateType=97&compatMode=normal
Thus it seems the reason the updates don't show up in about:addons is something within Waterfox.
Edit: It's what I thought. See relevant code in https://github.com/MrAlex94/Waterfox/blob/7cae1b00bfcd2454f09c56dfaab4facd48bb6c6b/toolkit/mozapps/extensions/internal/AddonUpdateChecker.jsm
Thanks for being patient with me!
The update URL example makes sense, but I understand only a little of the code; can't get the big picture.
Does something in AddonUpdateChecker.jsm cause the check to be made as if the appVersion and currentAppVersion are 56.something, ignoring what's specified in the URL?
The URL is only about how AMO treats it. Internally, Waterfox is checking its version (56.1.0) against the update manifest (which, in the example update URL, only specifies updates for 57). Thus Waterfox thinks the updates are not compatible, so doesn't offer anything.
It looks as though there might be a way to explicitly specify what appversion & platform version Waterfox should compare to when scanning an update manifest, and possibly on a per-addon basis. But offhand I'm not seeing how to specify it, or if it's possible without patching Waterfox.
(See references to Services.appinfo.version and Services.appinfo.platformVersion in AddonUpdateChecker.jsm.)
Two key aspects to this issue:
Also: strictly speaking, the issue title is outdated. For now, for consistency with the opening post etc., I'll not change the title.
Meta, tracking: #538 (application), #582 (web site), #603 (FAQ).
.
Whilst this open issue 484 requires no immediate action, it may become desirable to (at least) document a handful of summary points for the benefit of end users who are curious about Waterfox 56.x interactions with AMO.
Considerations include the possibility of more newcomers to Waterfox (not necessarily 'power' users) during Mozilla's countdown to the end of extended support for Firefox ESR 52.9. Reference:
Parallel consideration:
FWIW, once the add-on archive is fully integrated, I can work on getting WF to pretend its v57 for the add-on store.
From https://github.com/mozilla/addons-frontend/issues/5263#issuecomment-400849943
… or inject a userscript into AMO that makes it work to fit their needs.
Might it help to have a script?
Or,
… getting WF to pretend its v57 for the add-on store.
– will that development make scripting redundant?
FWIW, once the add-on archive is fully integrated, I can work on getting WF to pretend its v57 for the add-on store.
From https://github.com/mozilla/addons-frontend/issues/5263#issuecomment-400849943 (closed) re: Waterfox/ in a UA string:
… or inject a userscript into AMO that makes it work to fit their needs.
@MrAlex94 the pretence of 57 aside, for a moment …
… can we inject something, for AMO to treat Waterfox 56.x as Firefox 56.0? Irrespective of general.useragent.override (or whatever the default UA might be for Waterfox > 56.2.2).
Contexts include https://github.com/MrAlex94/Waterfox/issues/178#issuecomment-407028195
Maybe find relevant expertise in a Seamonkey area. I vaguely recall an extension for Seamonkey that customised the AMO experience.
56.2.3 is a milestone for this issue:
Spun off from 3391281#commitcomment-28209247
I guess that we also need attention to:
* `extensions.update.background.url`– and maybe more importantly,
* `extensions.update.url`
Just to come back to this, these parameters do not get overriden by the UA, they parse the internal version number.
Most helpful comment
Sorry, I'm slowly adding and testing the APIs in 57. I figured for now, some add-ons work; so best to make it not look like Waterfox doesn't support anything.