-
-
Notifications
You must be signed in to change notification settings - Fork 345
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
Comments
…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.
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? |
So if (for example) you install Conex 0.0.78, then about:addons can find and install:
– yes? (Do I understand correctly?) |
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? :) |
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. |
Yes and no :) From the commit:
– and from yesterday's #413 (comment):
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 #484 (comment) above) release notes MixturesFrom 3391281#commitcomment-28225332
about:addons updates to extensions for 57If 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 57Kicking 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 |
@grahamperrin Quantum is not mainly about extensions. The Quantum-ness of the browser is irrelevant.
Nice! Thanks for the answer.
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? |
Understood, thanks, note the quotation marks within the quote :-) |
Fixed in 22dcd9a . Many thanks! 😃 |
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 I'll await release notes before any change to the title of this issue. |
https://mozilla.logbot.info/amo/20180322#c14502837
https://mozilla.logbot.info/amo/20180331#c14543912
… no answer yet, I'll try to catch someone there during a weekday. |
You also need to change |
Thanks,
Hmm, I certainly did change both preferences at one point during the last round of experiments (before my second post to the The two defaults, with 56.1.0_2 on FreeBSD-CURRENT: 1.
|
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.
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 |
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 |
NBTwo 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: mozilla/addons-frontend#538 (application), mozilla/addons-frontend#582 (web site), mozilla/addons-frontend#603 (FAQ). 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 mozilla/addons#11883
Might it help to have a script? Or,
– will that development make scripting redundant? |
From mozilla/addons#11883 (closed) re:
@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 Contexts include #178 (comment) AfterthoughtMaybe 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:
|
Just to come back to this, these parameters do not get overriden by the UA, they parse the internal version number. |
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
The text was updated successfully, but these errors were encountered: