527249 - [ACR Extension] Support new compatibility checking preference

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Compatibility Tools, defect, P1)

Description

[Justin Scott [:fligtar]]

The compatibility checking preference is changing soon: http://www.oxymoronical.com/blog/2009/11/Changing-the-checkCompatibility-preference

I guess this means we'll need to flip the preference based on the version number, which I think means when someone upgrades, they would have to restart a second time for the extensions to be enabled. Unless we could do the flip when Firefox has installed an update and is waiting for a restart.

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Hm. I think the best solution here would be to reset the ACR (ie: re-show the page and reset all existing "this add-on works!" settings) anytime the value flips EXCEPT for when it flips from a beta to final.

For example, using the 3.6 -> 3.7 lifecycle, we would have had three values:

extensions.checkCompatibility.3.6a
extensions.checkCompatibility.3.6b
extensions.checkCompatibility.3.6
extensions.checkCompatibility.3.7a or 3.7


If the user installed ACR during alphas, we'd want to reset compatibility information when they moved to betas since there's no guarantee or expectation that add-ons should automatically continue to work. However, when moving from beta to final, that expectation *does* exist, and so the information should be preserved.

Of course, when the version number changes, it should also be reset.

Comment 3

[Justin Scott [:fligtar]]

Right now we reset reports anytime the version number changes at all, even between alphas and betas.

I still think we're going to have the restart twice issue.

Comment 4

[Justin Scott [:fligtar]]

I filed bug 529100 to fix the current issues people are having sooner than this bug's fix.

Comment 5

[David McNamara [:mackers]]

The compatibility information is reset when the add-on notices a change in the application version number returned by nsIXULAppInfo (as opposed to any value of a checkCompatibility pref). E.g.:

"3.6" -> "3.7"      [RESET]
"3.6" -> "3.7a5pre" [RESET]
"3.7a5pre" -> "3.7" [RESET]

If I'm not mistaken, beta builds do not include any indication of this fact in their version number, so the behaviour should already be not to reset compatibility information on upgrade from beta to final. E.g.:

"3.7" (beta) -> "3.7" (final)  [NO RESET]

Please inform if I am missing something here...

Comment 6

[Dave Townsend [:mossop]]

The beta builds will be 3.7b1, 3.7b2, ... etc. So yes you'll need to handle those too.

Comment 7

[David McNamara [:mackers]]

Ok, this is implemented in r69112.

The previous behaviour was to reset the compatibility report information regardless of minor version number upgrades.

Does this still make sense? Should we only reset the information on major version number upgrades?

"3.6.3" -> "3.7"   [RESET]
"3.6.3" -> "3.6.4" ??

Comment 8

[LegNeato]

I think only major versions would be fine. I doubt we'd take a change on branches that made plugins incompatible (unless it was a security fix and I'm sure we would message it). Though I'm not sure it is worth the risk changing behavior at this point.

Comment 9

[Justin Scott [:fligtar]]

Yeah, I agree with Christian. We should reset on individual betas but not on minor releases.

Comment 10

[David McNamara [:mackers]]

Ok, I have implemented this behaviour in r69557.

The reset behaviour is defined as follows:

- Major version upgrade (3.6 -> 3.7) [RESET]
- Upgrade from/to alpha (3.7apre5 -> 3.7) [RESET]

- Minor version upgrade (3.6.3 -> 3.6.4) [NO RESET]
- Upgrade from/to beta (3.6b1 -> 3.6) [NO RESET]

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Lemme reopen the bug for now until we have the following questions solved. As far as I can see it doesn't work well on stable branches.

* Imagine users flip between Firefox 3.6.x release builds and Nightly builds. Right now we always reset the flag. I don't think we should do that. It is the same situation as what Christian explained above. Nothing should break. As example take Firefox 3.6.6 and Namoroka 3.6.7pre.

* When are API changes expected? Doesn't it only occur for alpha and beta releases? That said, shouldn't we better search for the existence of "a" or "b" inside the minor version part? And only if those appear for the former or current build reset the flags? 

Summary:
========
* Stable branches
** Firefox 3.6.4 -> 3.6.6 [NO RESET]
** Firefox 3.6.6 -> Namoroka 3.6.7pre [NO RESET]

* Pre-release branch (trunk)
** Minefield 3.7a1 -> 3.7a2 [RESET]
** Minefield 3.7a5 -> 3.7b2 [RESET]
** Minefield 3.7a5 -> 3.7 [RESET]

* Major upgrade
** Firefox 3.6.6 -> 3.7a5 [RESET]
** Firefox 3.6.6 -> 4.0b2 [RESET]
** Firefox 3.6.7pre -> 4.0 [RESET]

Comment 12

[David McNamara [:mackers]]

(In reply to comment #11)
> Lemme reopen the bug for now until we have the following questions solved. As
> far as I can see it doesn't work well on stable branches.

This should work as expected on stable branches. Please re-open if necessary.
 
> * Imagine users flip between Firefox 3.6.x release builds and Nightly builds.
> Right now we always reset the flag. I don't think we should do that. It is the
> same situation as what Christian explained above. Nothing should break. As
> example take Firefox 3.6.6 and Namoroka 3.6.7pre.

This should be the existing behaviour. It won't reset the reports when upgrading from a branch release to a branch nightly.
 
> * When are API changes expected? Doesn't it only occur for alpha and beta
> releases? That said, shouldn't we better search for the existence of "a" or "b"
> inside the minor version part? And only if those appear for the former or
> current build reset the flags? 

Ok. I've modified the reset behaviour slightly to reset on all beta upgrades too. r75861

As it stands, the compatibility reports are reset when:

1. There is a major version upgrade.
2. There is an upgrade to or from an alpha or beta build.

Summary:
========
* Stable branches
** Firefox 3.6.4 -> 3.6.6 [NO RESET]
** Firefox 3.6.6 -> Namoroka 3.6.7pre [NO RESET]

* Pre-release branch (trunk)
** Minefield 3.7a1 -> 3.7a2 [RESET]
** Minefield 3.7a5 -> 3.7b2 [RESET]
** Minefield 3.7a5 -> 3.7 [RESET]
** Minefield 3.7b1 -> 3.7 [RESET]

* Major upgrade
** Firefox 3.6.6 -> 3.7a5 [RESET]
** Firefox 3.6.6 -> 4.0b2 [RESET]
** Firefox 3.6.7pre -> 4.0 [RESET]

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Tested all possible paths I can for now. Everything looks fine. Marking as verified fixed.