620349 - Add-ons compatibility check not performed for Testpilot when upgrading from 4.0b7 to 4.0b8

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

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

Attachment: extensions.sqlite

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8) Gecko/20100101 Firefox/4.0b8

On bug 620053 we have discovered that on some machines the add-ons compatibility check is not performed when upgrading from 4.0b7 to 4.0b8 on the betatest channel. It happens on all of my machines and the ones which are used for Mozmill in our QA lab. Testpilot is not compatible with 4.0b8 and should be disabled after the upgrade.

Here the log from the Error Console:

LOG addons.manager: Application has been upgraded
LOG addons.xpi: startup
LOG addons.xpi: Skipping unavailable install location app-system-share
LOG addons.xpi: checkForChanges
LOG addons.xpi: Opening database
LOG addons.xpi: Add-on [e-mail] modified in app-global
LOG addons.xpi: Add-on {972ce4c6-7e08-4474-a285-3208198ce6fd} modified in app-global
LOG addons.xpi: Updating database with changes to installed add-ons
LOG addons.xpi: Updating add-on states
LOG addons.xpi: Writing add-ons list

From the troubleshooting page:

        Feedback
        1.0.3
        true
        [e-mail]

Attached the extensions.sqlite file can be found from after the upgrade.

Comment 1

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

We should always correctly apply compatibility updates. Asking for blocking.

Comment 2

[Dave Townsend [:mossop]]

Just realised what this is. We skip doing the compatibility sync when the only installed extensions are in the application directory on the assumption that those will have shipped with the application and so have the right compatibility info. There isn't anything new about this, Firefox 3.x did the same so this isn't a regression and won't block.

It's probably a wontfix as there really isn't much of a case where doing this is a problem, in bug 620053's case it actually hid a bug with the update service's incorrect compatibility info. I wouldn't mind hearing from Rob first though.

Comment 3

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

So why it was working for Juan and Testpilot got disabled because it was incompatible on AMO?

Comment 4

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

(In reply to comment #3)
> So why it was working for Juan and Testpilot got disabled because it was
> incompatible on AMO?

As he said over on bug 620053, he used a fresh profile for testing. So no other extension was (hopefully) installed.

Comment 5

[Dave Townsend [:mossop]]

(In reply to comment #4)
> (In reply to comment #3)
> > So why it was working for Juan and Testpilot got disabled because it was
> > incompatible on AMO?
> 
> As he said over on bug 620053, he used a fresh profile for testing. So no other
> extension was (hopefully) installed.

Can we confirm that, even an extension installed in the registry would change this.

Comment 6

[Robert Strong (they/them - no direct email)]

(In reply to comment #2)
> Just realised what this is. We skip doing the compatibility sync when the only
> installed extensions are in the application directory on the assumption that
> those will have shipped with the application and so have the right
> compatibility info. There isn't anything new about this, Firefox 3.x did the
> same so this isn't a regression and won't block.
Unless I'm mistaken or the behavior changed on 3.x we didn't show the compatibility wizard or sync compatibility when there were only appManaged extensions which is different than extensions installed into the app dir. Now that is gone I would think it should whenever there is an extension that can / should have its compatibility info sync'd.

Comment 7

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

(In reply to comment #5)
> Can we confirm that, even an extension installed in the registry would change
> this.

I have tested this now with the Microsoft Framework installed and you are right. That's exactly the problem here. Shouldn't we simply disallow to overwrite compatibility information in the database for application wide installed add-ons?

Comment 8

[Dave Townsend [:mossop]]

(In reply to comment #6)
> (In reply to comment #2)
> > Just realised what this is. We skip doing the compatibility sync when the only
> > installed extensions are in the application directory on the assumption that
> > those will have shipped with the application and so have the right
> > compatibility info. There isn't anything new about this, Firefox 3.x did the
> > same so this isn't a regression and won't block.
> Unless I'm mistaken or the behavior changed on 3.x we didn't show the
> compatibility wizard or sync compatibility when there were only appManaged
> extensions which is different than extensions installed into the app dir. Now
> that is gone I would think it should whenever there is an extension that can /
> should have its compatibility info sync'd.

Good point, we have basically changed the meaning of appManaged so this is kind of a change in behaviour after all and maybe it should block.

(In reply to comment #7)
> (In reply to comment #5)
> > Can we confirm that, even an extension installed in the registry would change
> > this.
> 
> I have tested this now with the Microsoft Framework installed and you are
> right. That's exactly the problem here. Shouldn't we simply disallow to
> overwrite compatibility information in the database for application wide
> installed add-ons?

I think that is overly restrictive in fact we've had the need to be able to do it ourselves.

Comment 9

[Dave Townsend [:mossop]]

Thought about it some more and though we probably should just make it always do the compat check it is something of an edge case so I wouldn't block the release on it.

Comment 10

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.