User Agent: Mozilla/5.0 (Windows NT 10.0; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20170819092915 Steps to reproduce: With Firefox Sync enabled at multiple computers, I installed Taborama <https://addons.mozilla.org/firefox/addon/taborama/> with Nightly 57 on Kubuntu. Actual results: I found the extension, which is reportedly not compatible with Firefox 55.0.2, installed to 55.0.2 on FreeBSD-CURRENT. Expected results: Extensions that have a minimum Firefox version requirement should not be synchronised to inferior versions.
(In reply to Graham Perrin from comment #0) > Extensions that have a minimum Firefox version requirement should not be > synchronised to inferior versions. Are you sure that min version is expressed correctly? What happens when you manually try and install that version on 55.0.2? In a nutshell, Sync just asks the builtin addon manager to install and addon given its ID, and that builtin manager should select the best version and fail if one can't be found, but that doesn't seem to be happening.
From the linked AMO page: > Works with Firefox 57.0a1 and later – and that seems to be supported by the developer's response to this: Firefox version requirements – reportedly for Firefox 57.0a1 and later but partially functional with 55.0.2 · Issue #23 · kesselborn/taborama <https://github.com/kesselborn/taborama/issues/23> Also from the AMO page, viewed with 55.0.3 on FreeBSD (FreeBSD unsupported by Mozilla, but currently treated as equivalent to Linux for the purposes of installation from AMO): > This add-on is not compatible with your version of Firefox. > View other versions | Download Anyway
(In reply to Graham Perrin from comment #2) > From the linked AMO page: > > > Works with Firefox 57.0a1 and later > > – and that seems to be supported by the developer's response to this: > > Firefox version requirements – reportedly for Firefox 57.0a1 and later but > partially functional with 55.0.2 · Issue #23 · kesselborn/taborama > <https://github.com/kesselborn/taborama/issues/23> From that, it sounds like the developer is stating it's known to only work partially with 55, but has declined to setup the metadata for the extension to explicitly state that 57 is the min version (otherwise it wouldn't be "partially functional" - it simply wouldn't install) I downloaded the xpi and there's no "application" entry, which is where version compatibility is typically reported IIUC (https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/applications) > Also from the AMO page, viewed with 55.0.3 on FreeBSD (FreeBSD unsupported > by Mozilla, but currently treated as equivalent to Linux for the purposes of > installation from AMO): > > > This add-on is not compatible with your version of Firefox. > > View other versions | Download Anyway But yeah, I see that too. I'll need to dig a little more...
Summary: extension for a superior version of Firefox (57.0a1 and later) synced to an inappropriate version (55.0.2) → Extension for newer Firefox version (57.0a1 and later) synced to incompatible version (55.0.2)
So, it looks like around the time this bug was filed the version on AMO had no compatibility info. Specifically, the very first version of this on AMO (Version 0.0.8) is missing it. All releases after that have had compat info, and are all listed >= 57 (there was a brief period where it was listed as >= 54 , but it was never published to AMO). It wasn't until the version released on Aug 28th (coincidentally version 0.0.28) that it had compat info. Webextensions that don't specify compat info are assumed (somewhat optimistically) to work all the way back to Firefox 42 -- by both the client (via extensions.webExtensionsMinPlatformVersion) and the AMO server (via amo.DEFAULT_WEBEXT_MIN_VERSION). Anyway, the reason that if we look at AMO's list for the addon now (the developer renamed the addon to "conex" for whatever reason), you can't install the earliest version is because of an issue in the amo server code here , essentially, if a version doesn't contain compatibility info, it uses the compat info for the addon itself (which is the latest). This seems dubious, but I guess it doesn't really matter since the legacy vesions aren't used for anything important AFAIK. This is basically a long-winded way of saying that, AFAICT, it's not actually a bug in Sync. And it was a misconfiguration in the extension -- we happened to install an extension that was missing some critical config info about the fact that it shouldn't work, in a reasonably brief window when it doesn't work. I don't think there's a way we could have known the extension didn't work before installing it. (FWIW, since logic like this only means so much in the face of complex interdependent systems, I double-checked that we do the right thing with this extension now, as well as with a few others, and I wasn't able to cause any bad behavior). : https://github.com/kesselborn/conex/blob/a5a4daece32eff2ed962581ebf671bcecbbdfb3b/manifest.json : https://addons.mozilla.org/en-US/firefox/addon/conex/versions/ : https://github.com/mozilla/addons-server/blob/d11c8b531af4b04d681eaabe2b432da632c6655e/src/olympia/addons/indexers.py#L231-L238
Working as intended.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.