896295 - AMO should have a way for developers to disable auto-increment of maxVersion, when testing done to confirm compatibility fails to detect incompatibility

Status: RESOLVED INCOMPLETE

(addons.mozilla.org Graveyard :: Developer Pages, defect)

Description

[Reşat SABIQ (Reshat)]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

It's hard to avoid the following issue as of now, when AMO fails to determine that the prior addon version isn't compatible with the new app version:
1. Set strictCompatibility="true"
for an addon meant to be compatible with Firefox x (maxVersion="x").
2. Uploaded that version and had it reviewed.

P.S. E.g., https://addons.mozilla.org/en-US/firefox/addon/QIRIMTATARCA-til-destesi/
This might not be considered an important addon by some, but i think lack of a way to say "don't auto-increment", because you are failing to see that it isn't compatible is a general issue, that could easily affect some other addons as well.


Actual results:

3. AMO changed addon to maxVersion="{x+1}" (even though that addon version isn't compatible with {x+1})
4. App caches the new maxVersion. If maxVersion is later reverted by the developer, that revert will at a maximum work only for user profiles that run after the revert for a certain amount of time and update the maxVersion back to the correct value (at a minimum, the cached maxVersion isn't changed back by the app at all: i haven't verified this yet).
5. User upgrades Firefox to x+1.
6. Firefox doesn't check for availability of new updates during upgrade (apparently due to 3. and 4.). 
7. User's mozilla app profile is broken, or the addon isn't working even though there are no visible signs of an issue (for instance, this used to happen for https://addons.mozilla.org/en-US/firefox/addon/blend-in).


Expected results:

Since ticket 889214 has been discarded, ideally there should be a way for the developer to set a flag somewhere in an AMO DB record saying "don't auto-increment maxVersion for my addon" (this would primarily be advantageous when AMO's testing in step 3 gives a false positive (incorrect conclusion of compatibility)): this would then lead to the addon getting disabled or updated during app upgrade (6. above), and prevent the issue in 7. above.

Comment 1

[Reşat SABIQ (Reshat)]

As of now, when such an issue is encountered there seem to be only 2 options:
a. Fix AMO's testing code for step 3. For most addon developers, this would be a daunting task: assuming there is time to dive into that code to begin with.
b. Put a dummy (perhaps 0-size) native component in the addon folder hierarchy: native addons' maxVersion isn't auto-incremented by the AMO based on a fixed rule.

Comment 2

[Reşat SABIQ (Reshat)]

0-size part of b. above is a guess, but in the absence of other options, i may have to try to verify it. If 0-size doesn't work, then b. is gonna be narrowed down to either
b.1. text file(s) (with native extension) with some explanatory text (just to make the size non-0);
b.2. real compiled and linked native component(s) just meant to work around this issue.

Comment 3

[Reşat SABIQ (Reshat)]

(In reply to Reşat SABIQ (Reshat) from comment #0)
> 4. App caches the new maxVersion. If maxVersion is later reverted by the
> developer, that revert will at a maximum work only for user profiles that
> run after the revert for a certain amount of time and update the maxVersion
> back to the correct value (at a minimum, the cached maxVersion isn't changed
> back by the app at all: i haven't verified this yet).
I have verified that once the app has seen maxVersion of {x+1} once (after AMO changes it to {x+1} at timepoint t1), even after the developer (me) changes it back to x (at timepoint t2 a few days or a week) after AMO changed it to {x+1}, the app treats maxVersion as {x+1} (thus ignoring the fact that maxVersion was changed from {x+1} back to {x} at time t2).

I.
To give some more details, i made 3 profiles before AMO incremented maxVersion to 23:
A. 22-to-23-maxVersion-22
B. 22-to-23-maxVersion-22-to-23
C. 22-to-23-maxVersion-22-to-23-to-22
II.
I then used profile A. only before AMO changed maxVersion to 23. I used profile B. once or twice after AMO changed maxVersion to 23, so that the app gets that update in the background (which takes about 7-to-9 minutes), but before me changing maxVersion back to 22. I used profile C. the same as profile B., but also used it once or twice after i changed maxVersion back to 22: i have verified that the app in fact got maxVersion of 22.* during version check.
III. After Firefox 23 release, i started a session using each profile. Result:
only profile A. treated the addon's maxVersion as 22.*. Profiles B. and C. treated it as 23.* (what AMO assigned it to).

Conclusion: any mozilla profile that is used for 7-to-9 minutes after AMO increments maxVersion based on a false positive (incorrect conclusion of compatibility) at time t1 will attempt to use an incompatible addon upon app upgrade (even if the developer changes maxVersion back to the correct value at time t2>t1 such that t2 is before app upgrade (release and installation)). And if the incompatibility is serious, the user profile could be corrupted and require fixing with -safe-mode (if user is geeky enough for it).

P.S. Another quirk is that (for an addon that had a change of strictCompatibility from "false" to "true" at some point) after time t2, Version Check returns the last version that didn't have a strictCompatibility="true" as compatible with version {x+1}: this may not cause any issues when all is said and done (at least if a higher version is already installed in the profile), but it threw me off (i was asking myself why it was returning the forth or so oldest version rather than nothing (since the compatible version hadn't been reviewed yet) or the last approved one) and is a kind of strange.

Comment 4

[KLB]

I have run into a situation where I need the existing version of my extension to terminate with FF29 if it is not updated to a newer version. Unfortunately, the automatic maxVersion bump will cause the extension to be flagged as compatible with FF29.  Having an option on AMO to override the automatic maxVersion bump for a given version of an extension would be very helpful.

Comment 5

[Sebastian Zartner [:sebo]]

The Firebug Working Group would also like to have this, because Firebug strongly relies on APIs of specific versions of Firefox. This already caused some troubles before. See bug 823840.

Sebastian