addons icon indicating copy to clipboard operation
addons copied to clipboard

Investigate cases where AMO is silently correcting `strict_min_version` and `strict_max_version`

Open diox opened this issue 1 year ago • 2 comments

Split from https://github.com/mozilla/addons/issues/9133

At upload time, AMO is silently overriding what the manifest says regarding strict_min_version and strict_max_version in some cases before recording ApplicationsVersions in the database:

  • When min is less than what it should be for the features requested, notably, for extensions:
    • When it's less than 109.0a1 and it's a manifest v3 extension
    • When it's less than 48.0 and no id was specified
    • When it's less than 48.0 and browser_specific_settings was used
    • When it's less than 42.0
  • When max is less than min (including when either have been silently corrected)

Overriding the min silently in that fashion is fine, I think. Overriding the max could lead to unexpected issues, because we're copying the (potentially corrected) min version, which is likely not what the developer intended. Someone specifying a strict_min_version of 48.0 and strict_max_version of 50.* with a manifest v3 for instance, would end up with a min of 109.0a1 and a max of the same value.

Ultimately though, that max should be ignored: despite the name of the manifest key, that shouldn't trigger the file to be recorded with strict_compatibility enabled, so AMO would not expose that value in its update service, and addons-frontend would ignore it completely.

Still, we should investigate whether or not we need to change this behavior.

/cc willdurand because this can affect other compatibility issues with Android.

┆Issue is synchronized with this Jira Task

diox avatar May 29 '23 12:05 diox

The whole "default to compatible, ignore the max version" is something that was introduced way back in Firefox 4 for XUL extensions, because at the time they needed to explicitly set the max version they were compatible with in the manifest.

I've looked into this as part of https://github.com/mozilla/addons/issues/9276. There are now less than 100 publicly listed extensions in the database with a max that is not *, regardless of the app. All of them relatively old without a lot of users.

There is no rush, but in the future I think we should:

  • Stop silently correcting max at upload and instead loudly complain about it when it's inconsistent
  • Drop strict_compatibility completely
  • Obey max version in frontend & update service at all times on AMO instead of silently ignoring it (in effect doing for every add-on what we currently do when strict_compatibility is enabled)

diox avatar Sep 04 '23 10:09 diox

Old Jira Ticket: https://mozilla-hub.atlassian.net/browse/ADDSRV-378

KevinMind avatar May 03 '24 17:05 KevinMind

In https://github.com/mozilla/addons/issues/14804 some of that logic around min was removed since the minimum version of Firefox we supported was bumped to 58. We continue to silently correct max however.

diox avatar Sep 03 '24 10:09 diox