627595 - Incompatible Add-on Check dialog breaks Mozmill update checks

Status: RESOLVED FIXED

(Mozilla QA Graveyard :: Mozmill Tests, defect)

Description

[u279076]

In certain cases during update tests there is a dialog which appears for checking for incompatible add-ons.  Specifically, this dialog pops up for updates for 3.7a1 through 3.7a4 to 4.0b9.  The result of not handling these dialogs is that no results appear for these builds (as if it was not run to begin with).

We need to update the update tests to check for and handle this dialog.

Comment 1

[u279076]

Attachment: Screenshot

Here's a screenshot of the dialog in question.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

This add-on is a global one and should never be installed in Firefox. You remember that we have added the pref to Mozmill 1.5.1? See bug 610797.

When you run the normal Mozmill tests, gets this extension still installed for current builds or only in the alpha releases? I assume the latter case, otherwise we have a regression.

Btw. we can't handle this compatibility check with Mozmill.

Comment 3

[u279076]

Right, it only appears for 3.7a1, a2, a3, and a4.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Can you also please check the older branches? If we also fail there we have to fix it in Mozmill as best in the 1.5.2 release.

Comment 5

[u279076]

(In reply to comment #4)
> Can you also please check the older branches? If we also fail there we have to
> fix it in Mozmill as best in the 1.5.2 release.

What specifically?

3.6.x -> 3.6.13?
3.5.x -> 3.5.16?
Any major update paths which should be check?

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

No update checks required. Just starting mozmill without any tests specified should be enough. Check the add-ons manager if the extension is installed.

Comment 7

[u279076]

Mozmill: 1.5.2pre
Shiretoko: 20100120 [add-on installed]
Namoroka: 20100120 [add-on installed]
Minefield: 20100120 [add-on NOT installed]
Add-on: Ubuntu Firefox Modifications 0.9rc2

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

So this dialog will appear right before the update gets downloaded. So also older branches will be affected once we have major updates working. We could handle this situation somehow via the UI but it's kinda bad. Instead we should simply disable this add-on. I will run some manual checks what's the best way to do that, without completely uninstalling the package from the VM.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

I tried those steps manually, but disabling the extension via the add-ons manager UI doesn't solve the problem. A restart is still necessary to let the compat check not appear.

Robert will have a look for the Mochitests later or next week. Until we know how to finally fix this issue I will uninstall the Ubufox package on our linux32 and linx64 box, so we don't end-up in trouble for major updates to beta10.

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Anthony, until Rob will be able to check existing Mochitests and we have a solution for it simply uninstall Ubufox on qa-set.

Comment 12

[u279076]

(In reply to comment #11)
> Anthony, until Rob will be able to check existing Mochitests and we have a
> solution for it simply uninstall Ubufox on qa-set.

Ok, done. For reference, the following packages have been uninstalled:
* ubufox 0.9~rc2-0ubuntu5.1
* xul-ext-ubufox 0.9~rc2ubuntu5.1

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

We have to morph this bug a bit, because now it also happens with the feedback add-on which is installed via the distribution directory into the users profile. There is no way for us to disable it. That's why we should expand our update tests to cover that additional wizard page. As given by Rob there will be no hidden preference to disable this compatibility check.

We should wait for the new API and shared modules, otherwise we would have to update the code again soon.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

(In reply to comment #13)
> We have to morph this bug a bit, because now it also happens with the
> feedback add-on which is installed via the distribution directory into the
> users profile. There is no way for us to disable it. That's why we should
> expand our update tests to cover that additional wizard page. As given by
> Rob there will be no hidden preference to disable this compatibility check.

Dave, I hope you can help us here. The issue which we have right now is that the Feedback add-on which gets delivered with Aurora as distributed extension gets installed into the profile even when enabledScopes is set to not allow extensions from the application (see also bug 591921). Because of that for any upgrade which involves a major version bump we fail, due to the additional software update ui.

I think there is something wrong with enabledScopes for extension distribution. We shouldn't install those extensions into the profile when app wide extensions are excluded.

Comment 15

[Dave Townsend [:mossop] (PTO until Aug 21st)]

(In reply to comment #14)
> (In reply to comment #13)
> > We have to morph this bug a bit, because now it also happens with the
> > feedback add-on which is installed via the distribution directory into the
> > users profile. There is no way for us to disable it. That's why we should
> > expand our update tests to cover that additional wizard page. As given by
> > Rob there will be no hidden preference to disable this compatibility check.
> 
> Dave, I hope you can help us here. The issue which we have right now is that
> the Feedback add-on which gets delivered with Aurora as distributed
> extension gets installed into the profile even when enabledScopes is set to
> not allow extensions from the application (see also bug 591921). Because of
> that for any upgrade which involves a major version bump we fail, due to the
> additional software update ui.
> 
> I think there is something wrong with enabledScopes for extension
> distribution. We shouldn't install those extensions into the profile when
> app wide extensions are excluded.

Good catch, filed bug 660898

Comment 16

[Dave Townsend [:mossop] (PTO until Aug 21st)]

(In reply to comment #14)
> (In reply to comment #13)
> > We have to morph this bug a bit, because now it also happens with the
> > feedback add-on which is installed via the distribution directory into the
> > users profile. There is no way for us to disable it. That's why we should
> > expand our update tests to cover that additional wizard page. As given by
> > Rob there will be no hidden preference to disable this compatibility check.
> 
> Dave, I hope you can help us here. The issue which we have right now is that
> the Feedback add-on which gets delivered with Aurora as distributed
> extension gets installed into the profile even when enabledScopes is set to
> not allow extensions from the application (see also bug 591921). Because of
> that for any upgrade which involves a major version bump we fail, due to the
> additional software update ui.

I guess I forgot, you can just set extensions.installDistroAddons to false to stop this happening too.

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

(In reply to comment #16)
> I guess I forgot, you can just set extensions.installDistroAddons to false
> to stop this happening too.

Thanks Dave. One question remains, what happens when we reset this preference? Can we then install the extension after a restart of Firefox, or is that also tracked like enabledScope and we do not install the extension anymore for that build.

Comment 18

[Dave Townsend [:mossop] (PTO until Aug 21st)]

(In reply to comment #17)
> (In reply to comment #16)
> > I guess I forgot, you can just set extensions.installDistroAddons to false
> > to stop this happening too.
> 
> Thanks Dave. One question remains, what happens when we reset this
> preference? Can we then install the extension after a restart of Firefox, or
> is that also tracked like enabledScope and we do not install the extension
> anymore for that build.

Nothing out of the ordinary, if extensions.installDistroAddons is true (or not set) and the application version changes, and distribution add-ons haven't previously been installed then they'll get installed.

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

That's what I thought. Thanks Dave. I will go with 'extensions.installDistroAddons' for the Mozmill fix in a new bug.

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Fixed in Mozmill. We pushed a new beta release to pyPI yesterday. So I will now update all of our instances.

Here an example test result:

* 5.0a2 => 6.0a2, minor, en-US, complete+fallback, aurora, 2011-06-01, '''PASS'''
** Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0a2) Gecko/20110516 Firefox/5.0a2 ID:20110516042002
** Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0a2) Gecko/20110531 Firefox/6.0a2 ID:20110531042003
** Passed 10 :: Failed 0 :: Skipped 0