669541 - Fix extensions.checkCompatibility.nightly to not disable compatibility in aurora builds

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Dave Townsend [:mossop]]

The code landed for bug 659048 seems to be broken in aurora builds so it has been backed out from there. We'll need to either fix this before the next merge or keep it backed out then.

Comment 1

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

Dave, I assume with broken you mean that in Aurora builds the compatibility checks were still disabled?

Comment 2

[Dave Townsend [:mossop]]

For some reason aurora was also using extensions.checkCompatibility.nightly as the preference to control compatibility checking instead of the version specific one as it should have been.

Comment 3

[Brian King [:kinger]]

If my understanding is correct, this does not affect the ACR extension at all right. i.e. no changes are needed?

Comment 4

[Tony Mechelynck [:tonymec]]

(In reply to comment #3)
> If my understanding is correct, this does not affect the ACR extension at
> all right. i.e. no changes are needed?

My understanding is the same: I have the ACR on SeaMonkey, and I see in about:config a lot of preferences that I never set myself, i.e., not only extensions.checkCompatibility.nightly, but also extensions.checkCompatibility.<version>, where <version> is all possible combinations of any of 2.1, 2.2, 2.3 and 2.4 with any of a, b, p, pre or nothing.

Comment 5

[Brian King [:kinger]]

(In reply to comment #4)
> My understanding is the same: I have the ACR on SeaMonkey, and I see in
> about:config a lot of preferences that I never set myself, i.e., not only
> extensions.checkCompatibility.nightly, but also
> extensions.checkCompatibility.<version>, where <version> is all possible
> combinations of any of 2.1, 2.2, 2.3 and 2.4 with any of a, b, p, pre or
> nothing.

See bug 665848.

Comment 6

[Dave Townsend [:mossop]]

(In reply to comment #3)
> If my understanding is correct, this does not affect the ACR extension at
> all right. i.e. no changes are needed?

Correct. Bug 659048 was only meant to affect nightly builds so backing it out on aurora leaves us in the state we want really. We don't want to have to do that everytime though.

Comment 7

[Dave Townsend [:mossop]]

Attachment: patch rev 1

I must have totally failed to test this on actual non-nightly builds, not sure why. The Makefile is wrong, MOZ_UPDATE_CHANNEL isn't set until after including autoconf.mk. I also corrected the spelling in the new flag.

The tests fail still because XPIProvider.jsm sets the constant PREF_EM_CHECK_COMPATIBILITY at load time but our xpcshell tests simulate restarts and switching application version in a way that doesn't actually reload XPIProvider.jsm as it is a JS module. I changed the test to explicitly unload XPIProvider.jsm to solve this and give us a more accurate test. In the process I found a couple of cases where we were using references to add-ons across restarts which is wrong but worked out when the restart was only simulated.

Comment 8

[Dave Townsend [:mossop]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/7f2895987cb7

Comment 9

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

http://hg.mozilla.org/mozilla-central/rev/7f2895987cb7

Comment 10

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

Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0a2) Gecko/20110811 Firefox/7.0a2

Comment 11

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

Dave, do we need a manual test here or is it well covered by the automated test?

Comment 12

[Dave Townsend [:mossop]]

(In reply to Henrik Skupin (:whimboo) from comment #11)
> Dave, do we need a manual test here or is it well covered by the automated
> test?

I think we're good here, the automated tests we have caught the problem.