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

[diox]

trafficstars

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]

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)

[KevinMind]

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

[diox]

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.