1249328 - Un-signed add-ons are not disabled after updating Firefox

Status: RESOLVED INVALID

(Firefox for Android Graveyard :: Add-on Manager, defect)

Description

[u421692]

Attachment: addon_signin_update_log

1. Install Aurora 46.0a2(2016-02-16)(where xpinstall.signatures.required=false)
2. Install "Crash me" from http://people.mozilla.org/~tmielczarek/crashme/
3. Update to latest Aurora
4. Open about:addons

Expected result:
Crash-me entry is removed from overflow menu and is disabled in about:addons

Actual result:
Crash-me entry is not removed from overflow menu and is enabled in about:addons

PS: After manually disabling Crash me addon, and refreshing about:addons page, Crash-me entry is removed from overflow menu and is disabled in about:addons, without the possibility of enabling again

Comment 1

[:Margaret Leibovic]

What does desktop do here? I would assume the shared add-on manager toolkit code would take care of this for us.

Comment 2

[Dave Townsend [:mossop]]

(In reply to :Margaret Leibovic from comment #1)
> What does desktop do here? I would assume the shared add-on manager toolkit
> code would take care of this for us.

It does with one problem. It only goes through and updates the add-on states on startup if the app version has changed. Since the change was uplifted to aurora you can update from an old 46.0a2 to a new 46.0a2 and the add-ons manager doesn't know the application has changed. Within a day the periodic signature checks will go through and disable any add-ons that require it.

Comment 3

[:Margaret Leibovic]

(In reply to Dave Townsend [:mossop] from comment #2)
> (In reply to :Margaret Leibovic from comment #1)
> > What does desktop do here? I would assume the shared add-on manager toolkit
> > code would take care of this for us.
> 
> It does with one problem. It only goes through and updates the add-on states
> on startup if the app version has changed. Since the change was uplifted to
> aurora you can update from an old 46.0a2 to a new 46.0a2 and the add-ons
> manager doesn't know the application has changed. Within a day the periodic
> signature checks will go through and disable any add-ons that require it.

Thanks for the quick reply. Given this information, I don't think there's anything we need to do to fix this bug. However, we should verify that this works as expected when we update beta.

We should also verify that the periodic signature check happens as expected. To do that, we could follow the STR here, but leave the browser alone for 24 hours than check in on it to make sure the add-on was disabled.

Comment 4

[Dave Townsend [:mossop]]

(In reply to :Margaret Leibovic from comment #3)
> (In reply to Dave Townsend [:mossop] from comment #2)
> > (In reply to :Margaret Leibovic from comment #1)
> > > What does desktop do here? I would assume the shared add-on manager toolkit
> > > code would take care of this for us.
> > 
> > It does with one problem. It only goes through and updates the add-on states
> > on startup if the app version has changed. Since the change was uplifted to
> > aurora you can update from an old 46.0a2 to a new 46.0a2 and the add-ons
> > manager doesn't know the application has changed. Within a day the periodic
> > signature checks will go through and disable any add-ons that require it.
> 
> Thanks for the quick reply. Given this information, I don't think there's
> anything we need to do to fix this bug. However, we should verify that this
> works as expected when we update beta.

You can also verify this now by installing an older aurora 45.0a2 build then upgrading to current aurora 46.0a2

Comment 5

[u421692]

Closing this as invalid based on the comments above.
When updating to 46.0a2 from 45.0a2, this works as expected.
I will also verify the scenario when periodic signature checks will go through and disable any add-ons that require it.