Closed Bug 669541 Opened 8 years ago Closed 8 years ago

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

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla8

People

(Reporter: mossop, Assigned: mossop)

References

Details

Attachments

(1 file)

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.
Dave, I assume with broken you mean that in Aurora builds the compatibility checks were still disabled?
Summary: Use extensions.checkCompatibility.nightly to disable compatibility in nightly builds → Fix extensions.checkCompatibility.nightly to not disable compatibility in aurora builds
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.
If my understanding is correct, this does not affect the ACR extension at all right. i.e. no changes are needed?
(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.
(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.
(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.
Attached patch patch rev 1Splinter Review
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.
Attachment #553276 - Flags: review?(robert.bugzilla)
http://hg.mozilla.org/mozilla-central/rev/7f2895987cb7
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla8
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0a2) Gecko/20110811 Firefox/7.0a2
Status: RESOLVED → VERIFIED
Dave, do we need a manual test here or is it well covered by the automated test?
Flags: in-litmus?
(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.
Flags: in-litmus? → in-litmus-
You need to log in before you can comment on or make changes to this bug.