638848 - add-ons in disabled state, need re-install

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect, P2)

Description

[Thomas Arend [:tarend]]

Attachment: Add-on in disabled state, can't be enabled

About once a day (maybe related to nightly updates) I see add-ons in a disabled state, "enable" is grayed out (see screenshot). The only chance is to uninstall and re-install.
This happens on a Galaxy S with Personas (see attachment) and also on my Galaxy Tab with Personas, Phony, Full Screen, Nightly Tester Tools (see screenshot 2).

Errors in console:
Warning: Cannot load binary component from jar. Source File: /data/app/org.mozilla.fennec-2.apk:components/components.manifest
Could not read chrome manifest file '/data/data/org.mozilla.fennec/chrome.manifest'.    Line: 35

Warning: WARN addons.repository: Unknown type id when parsin addon: 3
Source File: resource://gre/modules/AddonRepository.jsm    Line: 898

Comment 1

[Thomas Arend [:tarend]]

Attachment: disabled add-ons on Galaxy Tab

I forgot to mention that Fennec is NOT installed on SD card.

Comment 2

[Matt Brubeck (:mbrubeck)]

Attachment: update XML

I'm also seeing this frequently on Android nightly builds, though not on desktop.  Pressing the "Update" button often re-enables the add-ons and displays a "compatibility update" message - even though I don't think these add-ons have not had any compatibility changes (I'm the author of several of them).

Right now on my Galaxy Tab, several of my add-ons are disabled and can't be enabled, even though they should be compatible.

I turned on "extensions.logging.enabled".  I don't see anything interesting at startup, though I can see that it does not run the bootstrap methods for the disabled add-ons.

When I press update, I see update checks for all the add-ons, including the disabled ones.  Here's the update URL from the log, and the XML response (attached) when I request the same URL from my desktop:

https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=2&id=[e-mail]&version=2.0&maxAppVersion=4.0b4&status=userEnabled,incompatible&appID={a23983c0-fd0e-11dc-95ff-0800200c9a66}&appVersion=4.0b6pre&appOS=Android&appABI=arm-eabi-gcc3&locale=en-US&currentAppVersion=4.0b6pre&updateType=97

It looks like maxAppVersion in the request is 4.0b4, which has not been true for a while.  maxVersion in the response is 4.0.*.

After pressing Update, Phony was enabled (but still appeared disabled in the add-on manager).  After restarting once, it was disabled again.  After pressing "Update" and restarting a second time, it was enabled, and now the update request correctly shows maxAppVersion=4.0.*.

I suspect that we are occasionally getting out-of-date or incorrect compatibility information in response to our AMO update checks.

Comment 3

[Wesley Johnston (:wesj)]

Pinging mossop as well, in case he has some idea what could cause this.

Comment 4

[Dave Townsend [:mossop]]

So it looks like the maxVersion for the add-on is reverting to 4.0b4 (what is in the install.rdf). Getting a copy of extensions.sqlite just to confirm that would be nice also a copy of extensions.log might reveal definitively what is going on.

My best guess at the moment though is that something is causing us to wipe the database and reload everything from the install.rdf files. A good indicator of that would be to install an extension that is compatible according to its rdf, then disable it and see if it enables itself.

Comment 5

[Wesley Johnston (:wesj)]

Nothing very interesting in the profile that we haven't already seen here. extensions.sqlite shows that the addon is only compatible with 4.0b4. Logging wasn't enabled when this occurred, so I have enabled it now and am trying to reproduce.

According to Thomas, this usually happens overnight, when background updates occur, so I am digging through that code and comparing to our "update button" code to look for differences, but they are (for the most part) the same.

Comment 6

[Wesley Johnston (:wesj)]

Also should note this is a multi-locale build, and does suffer from bug 642203. Matt's build (above) does not seem to have that problem, so I am assuming its not 100% responsible for this.

Comment 7

[Dave Townsend [:mossop]]

(In reply to comment #5)
> Nothing very interesting in the profile that we haven't already seen here.
> extensions.sqlite shows that the addon is only compatible with 4.0b4. Logging
> wasn't enabled when this occurred, so I have enabled it now and am trying to
> reproduce.

Logging doesn't need to be enabled for extensions.log to have useful info.

Comment 8

[BMO Automation]

Closing all opened bug in a graveyard component