The default bug view has changed. See this FAQ.

When an add-on moves to a different directory but doesn't change in any other way we should keep updated compatibility information

VERIFIED FIXED in Firefox 7

Status

()

Toolkit
Add-ons Manager
P1
major
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: xti, Assigned: mossop)

Tracking

Trunk
mozilla7
ARM
Android
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +
in-litmus -

Firefox Tracking Flags

(firefox5 wontfix, firefox6 wontfix, firefox7 fixed, status2.0 wontfix, fennec7+)

Details

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
Created attachment 530617 [details]
Disabled addons

Build id : Mozilla/5.0 (Android;Linux armv7l;rv:6.0a1)Gecko/20110506
Firefox/6.0a1 Fennec/6.0a1
Device: HTC Desire
OS: Android 2.2

Steps to reproduce:
1. Open Fennec App
2. Install at least 1 add-on
3. Quit Fennec
4. Move Fennec App to SD Card
5. After the app is moved reopen it
6. Go to Addons Manager

Expected result:
After step 6, addons installed at step 2 are still active and user is able at least to disable them.

Actual result:
Addons are disabled and buttons "Options" and "Enable" are grayed out. User is able only to uninstall those addons.

Note:
If after step 5, are repeated steps 2-3 and then the app is moved back to internal memory, all the installed addons are disabled.
Please see the attached screenshot.
(Reporter)

Updated

6 years ago
Priority: -- → P1
Dave - I am working under the assumption the when an add-on is installed, we remember the absolute install path. When we move the profile, the install path is no longer valid.

If this is true, is there a way to "rebase" the add-ons?
(Assignee)

Comment 2

6 years ago
The code should be detecting this. Can you enable extensions.logging.enabled and get a log of the text console of the first startup after the app is moved?
(Reporter)

Comment 3

6 years ago
(In reply to comment #2)
> The code should be detecting this. Can you enable extensions.logging.enabled
> and get a log of the text console of the first startup after the app is
> moved?

I've installed 3 add-ons (Quit Fennec, Personas and Nightly Tester Tools) and here is the log just after I've moved the app to SD card:

LOG addons.xpi: Writing add-ons list
LOG addons.xpi: Updating add-ons states
LOG addons.xpi: Updating database with changes to installed add-ons
LOG addons.xpi: Add-on nightly@mobile.mozilla.org modified in app-profile
LOG addons.xpi: Add-on mask@desre.org modified in app-profile
Blocklist::_loadBlocklist: no XML File found
LOG addons.xpi: Add-on quitfennec@mbrubeck.limpet.net modified in app-profile
LOG addons.xpi: Opening database
LOG addons.xpi: checkForChanges
LOG addons.xpi: startup
Could not read chrome manifest file '/data/data/org.mozilla.fennec/chrome.manifest'.
Warning: Cannot load binary components from a jar.
Source File: /mnt/asec/org.mozilla.fennec-1/pkg.apk:components/components.manifest Line: 35
(Reporter)

Comment 4

6 years ago
After I've updated the app with the latest build (20110509), there is one more warning about addons:
Warning: WARN addons.repository: Unknown type id when parsing addon: 3
Source File: resource://gre/modules/AddonRepository.jsm
tracking-fennec: --- → ?
Flags: in-testsuite?
Flags: in-litmus?
(Assignee)

Comment 5

6 years ago
Strange, the log suggests that it spotted that the add-ons had moved. Can you attach a copy of extensions.sqlite from the profile before and after the move?
(Assignee)

Comment 6

6 years ago
Actually I can see this happening now. Looks like on the second startup on the sdcard things start working again?
(Assignee)

Comment 7

6 years ago
I think I know what is going on here. All of the add-ons I've found to test are marked compatible up to 4.0.* in their install.rdf but have been bumped to 6.0.* on AMO which is why they install ok. When an add-on has changed directory on startup we basically throw away the updated compatibility info and just use the facts from install.rdf.
(Assignee)

Comment 8

6 years ago
Ok, confirmed this is the case. I guess if the add-on keeps the same version number then we probably should keep the compatibility info in the database
Component: General → Add-ons Manager
Product: Fennec → Toolkit
QA Contact: general → add-ons.manager
Summary: Moving Fennec to SD Card doesn't change the add-ons path → When an add-on moves to a different directory but doesn't change in any other way we should keep updated compatibility information
Version: Firefox 5 → Trunk
(Reporter)

Comment 9

6 years ago
Created attachment 531272 [details]
extensions.sqlite

I've attached the extensions.sqlite after I've moved the app to SD Card, but I do not have access to device /data/. The device should be rooted, but I cannot do that.
There is another file on SD Card "extensions.sqlite-journal". I will attach it too. Maybe it would be helpful.
(Reporter)

Comment 10

6 years ago
Created attachment 531273 [details]
extensions.sqlite-journal
Dave - what kind of timeframe ETA do you have for this bug?
tracking-fennec: ? → 6+
(Assignee)

Updated

6 years ago
Assignee: nobody → dtownsend
(Assignee)

Updated

6 years ago
Blocks: 657019
(Assignee)

Comment 12

6 years ago
Created attachment 535740 [details] [diff] [review]
patch rev 1

This fix works for the case we are concerned with. The install location has moved and so the extension's directory has changed but nothing else about it has. Fennec's code for moving the profile to the sdcard takes steps to ensure the file modification times remain the same so we rely on that. This includes a test and I've also build this for android and tested it manually to verify it works.
Attachment #535740 - Flags: review?(robert.bugzilla)
(Assignee)

Updated

6 years ago
Whiteboard: [has patch][needs review rs]
Comment on attachment 535740 [details] [diff] [review]
patch rev 1

>diff --git a/toolkit/mozapps/extensions/XPIProvider.jsm b/toolkit/mozapps/extensions/XPIProvider.jsm
>--- a/toolkit/mozapps/extensions/XPIProvider.jsm
>+++ b/toolkit/mozapps/extensions/XPIProvider.jsm
>@@ -2168,17 +2168,17 @@ var XPIProvider = {
>    * @param  aMigrateData
>    *         an object generated from a previous version of the database
>    *         holding information about what add-ons were previously userDisabled
>    *         and updated compatibility information if present
>    * @param  aActiveBundles
>    *         When performing recovery after startup this will be an array of
>    *         persistent descriptors of add-ons that are known to be active,
>    *         otherwise it will be null
>-   * @return true if a change requiring a restart was detected
>+   * @return true if a change requiring flushing the caches was detected
>    */
>   processFileChanges: function XPI_processFileChanges(aState, aManifests,
>                                                       aUpdateCompatibility,
>                                                       aOldAppVersion,
>                                                       aOldPlatformVersion,
>                                                       aMigrateData,
>                                                       aActiveBundles) {
>     let visibleAddons = {};
>@@ -2192,17 +2192,17 @@ var XPIProvider = {
>      *
>      * @param  aInstallLocation
>      *         The install location containing the add-on
>      * @param  aOldAddon
>      *         The AddonInternal as it appeared the last time the application
>      *         ran
>      * @param  aAddonState
>      *         The new state of the add-on
>-     * @return true if restarting the application is required to complete
>+     * @return a boolean indicating if flushing caches is required to complete
>      *         changing this add-on
nit: just noticed this. You use "@return true..." above and "@return a boolean..." here. I'd prefer consistency throughout the file.
(Reporter)

Comment 14

6 years ago
This issue is reproducing on Beta 5:
Build id : Mozilla/5.0 (Android;Linux armv7l;rv:5.0)Gecko/20110527
Firefox/5.0 Fennec/5.0
Device: LG Optimus 2X
OS: Android 2.2
status2.0: --- → wontfix
status-firefox5: --- → affected
status-firefox6: --- → affected
status-firefox7: --- → affected
(Assignee)

Comment 15

6 years ago
Created attachment 537233 [details] [diff] [review]
patch rev 2

Corrected the comment
Attachment #535740 - Attachment is obsolete: true
Attachment #535740 - Flags: review?(robert.bugzilla)
Attachment #537233 - Flags: review?(robert.bugzilla)
Attachment #537233 - Flags: review?(robert.bugzilla) → review+
(Assignee)

Updated

6 years ago
Whiteboard: [has patch][needs review rs] → [has patch]
(Assignee)

Comment 16

6 years ago
Landed: http://hg.mozilla.org/mozilla-central/rev/fbeb460473f5
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite?
Flags: in-testsuite+
Flags: in-litmus?
Flags: in-litmus-
Resolution: --- → FIXED
Whiteboard: [has patch]
Target Milestone: --- → mozilla7
Cristian, can you please verify this fix?
(Reporter)

Comment 18

6 years ago
VERIFIED FIXED on:

Build id : Mozilla/5.0 (Android;Linux armv7l;rv:7.0a1)Gecko/20110623
Firefox/7.0a1 Fennec/7.0a1

Device: Motorola Droid 2
OS: Android 2.2
Status: RESOLVED → VERIFIED
tracking-fennec: 6+ → 7+
status-firefox5: affected → wontfix
status-firefox6: affected → wontfix
status-firefox7: affected → fixed
(Assignee)

Updated

6 years ago
Duplicate of this bug: 675854

Comment 20

6 years ago
This does not work for unpacked extensions, which will be nearly all of them for older upgraded profiles (my case).  Copying such a profile changes the folder modified dates and the extensions remain disabled (Fx7).
(Assignee)

Updated

5 years ago
Depends on: 744833
You need to log in before you can comment on or make changes to this bug.