Closed Bug 718416 Opened 14 years ago Closed 13 years ago

Allow tests to unset the disable add-on compatibility checks preference set by Mozmill by default

Categories

(Testing :: Mozbase, defect)

Product:
Testing
Component:
Mozbase
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: whimboo, Unassigned)

References

Details

(Whiteboard: [mozmill-2.0+][fixed by 751108])

In the past we have set the 'extensions.checkCompatibility.x' pref to ensure that the Mozmill and JSBridge add-on will always be compatible. Given our efforts on bug 718403 we have to think about a way that we can tests let override this setting. Without it we will not have true compatibility results.
So after a further check we probably don't have to do anything here for Mozmill 1.5. Given our current set of preferences: # Disable addon compatibility checks 'extensions.checkCompatibility' : False, 'extensions.checkCompatibility.4.0' : False, 'extensions.checkCompatibility.4.0b' : False, [..] 'extensions.checkCompatibility.9.0' : False, 'extensions.checkCompatibility.9.0a' : False, 'extensions.checkCompatibility.nightly' : False, We do not have disabled check compatibility for Firefox 10. In newer versions of Mozmill starting with 2.0 we dynamically determine the application version and set the correct preference. So here we have to make a decision how to continue.
(In reply to Henrik Skupin (:whimboo) from comment #1) > In newer versions of Mozmill starting with 2.0 we dynamically determine the > application version and set the correct preference. So here we have to make > a decision how to continue. We're not using Mozmill 2.0 for bug 718403. I'm not sure why we have to make a decision here or what decision it is that we're making. Can you be more clear?
We don't do it yet, but who knows about our state in about 1 month? It's a situation we will have to fix. Otherwise our addon compatibility testing will be broken later.
(In reply to Henrik Skupin (:whimboo) from comment #3) > We don't do it yet, but who knows about our state in about 1 month? It's a > situation we will have to fix. Otherwise our addon compatibility testing > will be broken later. I'm sorry, I'm really not following you. Do you mean that because we don't do the "automatic preference setting for compatibility" in mozmill 1.5.x, then we need to fix that before we release firefox with "compatible by default"? Why is that the case? Once we switch to "compatible by default" it shouldn't matter at all because we'll always be compatible.
(In reply to Clint Talbert ( :ctalbert ) from comment #4) > I'm sorry, I'm really not following you. Do you mean that because we don't > do the "automatic preference setting for compatibility" in mozmill 1.5.x, > then we need to fix that before we release firefox with "compatible by > default"? Nothing has to be fixed in Mozmill 1.5.x. It only affects Mozmill 2.0 and upwards. > Why is that the case? Once we switch to "compatible by default" it > shouldn't matter at all because we'll always be compatible. No, that would mean we enable *ALL* add-ons even those which have been explicitly marked as not compatible, due to known brokenness. That's not what we want to have.
ok excellent. Now I understand. Thanks Henrik. Jeff, would this be a mozrunner or mozprofile change?
mozprofile, as things stand. You should be able to override preferences by adding a contradictory preference following the initial set. If that doesn't work, it is a bug. If that does work, it should suffice, though it will have to be done at the python harness level, not at the JS test level, although conceivably you could leverage ManifestDestiny to this end.
Ok, good to hear Clint. I know the add-on system is quite complex, but while being the QA lead for the AOM I was able to understand most of it. I will try to explain issues better in the future. So what about removing the automatic handling of the compatibility preference and let it fully control with the test-run invocation? Ok, for now we would have to wait for the agreement that compatible by default will stay enabled for Firefox 10, but once done I think we would be ok in removing this code. If a test-run has to enable all add-ons it should be specified by a preference. I don't think that we can implement some logic in Mozmill itself. At least such an automatic handling will completely fail for our update tests, where we do not know to which specific version Firefox/Thunderbird will be upgraded to. And setting such a pref would even require a restart.
This should have been filed under Mozbase. It would be necessary for us to run DTC tests with Mozmill 2.0
Component: Mozmill Automation → Mozbase
Product: Mozilla QA → Testing
QA Contact: mozmill-automation → mozbase
Whiteboard: [mozmill-2.0?]
Fixed by 751108 \o/
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Depends on: 751108
Whiteboard: [mozmill-2.0?] → [mozmill-2.0+][fixed by 751108]
You need to log in before you can comment on or make changes to this bug.