Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Waterfox 56.1.x to be treated as if it's … 57 for add-on services e.g. AMO #484

Closed
grahamperrin opened this issue Mar 22, 2018 · 21 comments

Comments

@grahamperrin
Copy link

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
grahamperrin referenced this issue Mar 22, 2018
…ity on the web unfortunately, too many sites check for browser name instead of feature detection. Pretend we're 57.0 as well, so add-ons install propely on the Mozilla AMO.
@laniakea64
Copy link

I 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?

@grahamperrin
Copy link
Author

… 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:

  • the update to 0.0.79 (Works with Firefox 57.0a1 and later)
  • but not the update to 0.0.80 (Works with Firefox 59.0a1 and later)

– yes? (Do I understand correctly?)

@laniakea64
Copy link

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 77516ff , 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? :)

@MrAlex94
Copy link
Collaborator

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.

@grahamperrin
Copy link
Author

grahamperrin commented Mar 22, 2018

… 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 #413 (comment):

… 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:

  • Add to Firefox

– and (this comment crossing paths with #484 (comment) 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).

Mixtures

From 3391281#commitcomment-28225332

… 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?

about:addons updates to extensions for 57

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.)

Compatibility checking and extensions that are (were) not for 57

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 …

@laniakea64
Copy link

@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?

@grahamperrin
Copy link
Author

… Quantum is not mainly about extensions. …

Understood, thanks, note the quotation marks within the quote :-)

@laniakea64
Copy link

Fixed in 22dcd9a . Many thanks! 😃

@grahamperrin
Copy link
Author

grahamperrin commented Mar 24, 2018

If I understand correctly, the commit will:

  • make checkCompatibility2 redundant
  • not allow AMO to treat Waterfox 56.1.0 as Firefox 57

– 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.

@grahamperrin grahamperrin changed the title Waterfox 56.1 to be treated as if it's … 57 for add-on services e.g. AMO Waterfox 56.1.x to be treated as if it's … 57 for add-on services e.g. AMO Mar 27, 2018
@grahamperrin
Copy link
Author

https://mozilla.logbot.info/amo/20180322#c14502837

Greetings from Waterfox land. If anyone with AMO expertise can help us with #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.url seem 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.

@laniakea64
Copy link

laniakea64 commented Apr 3, 2018

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.url seem 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.

@grahamperrin
Copy link
Author

grahamperrin commented Apr 4, 2018

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:

1. extensions.update.url

https://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%&currentAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE%

2. extensions.update.background.url

https://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%&currentAppVersion=%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:

  • what part of the string should I change, for a manual check at about:addons to get updates to extensions that require 57.x?

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.)

@laniakea64
Copy link

laniakea64 commented Apr 4, 2018

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&currentAppVersion=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

@grahamperrin
Copy link
Author

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?

@laniakea64
Copy link

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.)

@grahamperrin
Copy link
Author

grahamperrin commented Jun 3, 2018

NB

Two key aspects to this issue:

  1. about:addons – the special page (special address)
  2. browsing – including installations, including updates – through normal page views of Add-ons for Firefox https://addons.mozilla.org/firefox/

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: mozilla/addons-frontend#538 (application), mozilla/addons-frontend#582 (web site), mozilla/addons-frontend#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:

@MrAlex94
Copy link
Collaborator

FWIW, once the add-on archive is fully integrated, I can work on getting WF to pretend its v57 for the add-on store.

@grahamperrin
Copy link
Author

From mozilla/addons#11883

… 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?

@grahamperrin
Copy link
Author

grahamperrin commented Jul 25, 2018

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 mozilla/addons#11883 (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 #178 (comment)

Afterthought

Maybe find relevant expertise in a Seamonkey area. I vaguely recall an extension for Seamonkey that customised the AMO experience.

@grahamperrin
Copy link
Author

56.2.3 is a milestone for this issue:

@MrAlex94
Copy link
Collaborator

MrAlex94 commented Jun 6, 2019

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.

@MrAlex94 MrAlex94 closed this as completed Jun 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants