356370 - "installLocation has no properties" during install/update of extensions (line 3849/_getActiveItems)

Status: VERIFIED FIXED

Description

[Daniel Hahler]

User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.5 (like Gecko) (Kubuntu)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1) Gecko/20060601 BonEcho/2.0 (Ubuntu-edgy)

I'm experiencing an "unknown error -203" during installation or update of extensions in firefox 1.99+2.0rc2+dfsg-0ubuntu1.
The error seems to prevent installing new extensions, while despite the error updating existing extensions seems to work (at least they don't show up after a restart as updateable anymore).
The error console shows:
 """
 installLocation has no properties
 file:///usr/lib/firefox/components/nsExtensionManager.js line: 3849.
 """
This is also present in the RC2 release.

It's basically the same issue as bug 352847, but I could not re-open nor leave a comment there.

Also, I'm not sure if the simple patch fixes the root of the problem.

Reproducible: Always

Steps to Reproduce:
1. Install or update an existing extension

Actual Results:  
 installLocation has no properties
 file:///usr/lib/firefox/components/nsExtensionManager.js line: 3849.
in error console

Comment 1

[Daniel Hahler]

Created attachment 242024 [details] [diff] [review]
Seems to fix the bug

Comment 2

[Robert Strong [:rstrong] (use needinfo to contact me)]

These types of errors are typically due to a bug that occurs earlier - sometimes during the previous launch of the application - and checks for a null installLocation ends up covering up the actual bug. Could you zip up and email me your profile's extensions directory along with the extensions.cache, extensions.ini, and extensions.rdf from your profile?

Comment 3

[Daniel Hahler]

I've emailed the files, but got no reply.

See https://launchpad.net/ubuntu/+source/firefox/+bug/65609 - the most easiest fix to this (has been) to delete extensions.rdf and let it get recreated.

Comment 4

[James]

I just upgraded to Firefox 2.0.0.2 and this bug is still present.

Comment 5

[Trent Larson]

Created attachment 261070 [details]
the contents of my extensions directory

From the Help -> About Mozilla Firefox:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Comment 6

[Trent Larson]

I have tried all these solutions:
- adding the patch (but it complains on the line BEFORE the patch)
- renaming extensions directory
- removing the extensions.rdf file (because that file doesn't exist anywhere under my firefox directory, and neither do extensions.ini nor extensions.cache)
- manually downloading the XPI file and opening it (with File->Open and with Tools->Add-ons)

I still get the problem.

Comment 7

[Ray Kirk]

Trent: Have you had any success yet? This web page lists the location of the Firefox profile folder which contains the "extensions.rdf" file. My apologies if this is "old news".  :-)

Comment 8

[Ray Kirk]

>> This web page lists the location of the Firefox profile folder.

Uggh! Here's that URL: http://kb.mozillazine.org/Profile_folder

Comment 9

[Trent Larson]

Thank you for that; I didn't realize there was an 'extensions' folder in the profile area.

Before trying this hack, though, I attempted to install an extension again and it succeeded this time!  Weird.  Maybe some automatic Firefox update helped.

Comment 10

[Thomas_H]

I installed Firefox 2.0.0.3 a few weeks ago and the bug was still present.

Comment 11

[[:Aleksej]]

Can anyone reproduce this with Firefox 2.0.0.6 or 2.0.0.7, or the latest trunk build? Thanks.

Comment 12

[Trent Larson]

I can still make this happen in v 2.0.0.6.  (I tried removing "extensions" folder; no go.  I previously reported that it was working; obviously not any more.)

Comment 13

[Marcus Better]

I just got this on Debian icedove 2.0.0.9.

Debian bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441961

Comment 14

[Dave Townsend [:mossop]]

Debugged this with the help of someone on IRC. What has happened is a switch from a build of Firefox that has been patched to support new install locations (many linux distributions do this) to a build that doesn't have the same set. This leaves entries in the datasource pointing to unknown install locations which causes the fail.

We should I think in checkForMismatches do a sweep through the rdf and wipe out any entries in install locations that we do not know about.

Comment 15

[Christopher Aillon (sabbatical, not receiving bugmail)]

Fun.  Hopefully, checkForMismatches doesn't add any extra overhead to penalize distros that try to not take invasive patches like this without getting them upstream first.  Fedora/Red Hat have never had any patches to add system install locations in our distro builds.  I made sure to push that work upstream first (bug 311008) so I wouldn't create a de facto standard that upstream didn't have.

Comment 16

[Dave Townsend [:mossop]]

(In reply to comment #15)
> Fun.  Hopefully, checkForMismatches doesn't add any extra overhead to penalize
> distros that try to not take invasive patches like this without getting them
> upstream first.  Fedora/Red Hat have never had any patches to add system
> install locations in our distro builds.  I made sure to push that work upstream
> first (bug 311008) so I wouldn't create a de facto standard that upstream
> didn't have.

checkForMismatches is only run when the application has been updated to a new version which is why I suggested there. It already takes a bit of a longer path to verify compatibility information etc., but the path should only be taken once per app update, not impacting the normal app startup.

Comment 17

[Mike Beltzner [:beltzner, not reading bugmail]]

Blocking as Mossop tells me this will affect all Linux users migrating when their distro moves from 2->3. Seems strange that we didn't get more dupes, though, if that's the case. I guess not many distros have done that?

Comment 18

[Dave Townsend [:mossop]]

(In reply to comment #17)
> Blocking as Mossop tells me this will affect all Linux users migrating when
> their distro moves from 2->3. Seems strange that we didn't get more dupes,
> though, if that's the case. I guess not many distros have done that?

All is not quite what I said. It will affect any Linux distribution that have previously patched their extension manager in this way. I know that this includes Ubuntu and SuSE. But I'll take the blocking+ anyway :)

Comment 19

[Mike Connor [:mconnor]]

Dave, ETA?

Comment 20

[Dave Townsend [:mossop]]

Created attachment 312699 [details] [diff] [review]
thorough patch

This is a full patch that would clear out any invalid install locations and even some corrupt datasource items on ever startup with practically no perf impact in the general case. However it is probably a little risky at this stage and the unit test I have that should be a pretty full test cannot run in our current testing environment. So just sticking this here because it might be nice to revisit this option in the future.

Comment 21

[Dave Townsend [:mossop]]

Created attachment 312742 [details] [diff] [review]
less aggressive

This is a safer approach since it only attempts to make changes and install items during checkForMismatches. The patch is slightly complicated since it was necessary to expose installItem, normally hidden inside checkForFileChanges.

The StartupCache just ignores any entries for invalid locations. They never get used so this will just clean them out next time the cache is written to disk.

In the main loop in checkForMismatches any items that appear to be in an invalid locations are added to an array for later processing. There the entry is removed from the datasource and then a check for any uncovered items is done, if so the item is installed and disabled if appropriate. The actual install will happen in the next finishOperations call.

As a stopgap measure in the event that an app version change hasn't happened and also to cover saving the changes of earlier operations before the corrupt entries are found, _getActiveItems is made to ignore items with invalid install locations.

When removing corrupt entries it is necessary to clear out their entry in visibleItems.

The testcase sets up a profile with 3 extensions supposedly installed in unknown locations. There are also 2 matching extensions dropped into the profile, one of which is active, the other shadowed by one of the unknown locations. It then starts up the EM and checks that only the 2 extensions in the profile remain. It then just checks that installation of a new extension works.

Comment 22

[Dave Townsend [:mossop]]

FYI we should be considering this for the branch. Not only is this an issue when switching from patched Linux builds, it will also be a problem when switching from Firefox 3 to Firefox 2 since we have added new install locations in 3.

Comment 23

[Robert Strong [:rstrong] (use needinfo to contact me)]

Comment on attachment 312742 [details] [diff] [review]
less aggressive

Looks good. It might be helpful to comment on what constitutes a badItem.

Comment 24

[Dave Townsend [:mossop]]

Checking in toolkit/mozapps/extensions/src/nsExtensionManager.js.in;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v  <--  nsExtensionManager.js.in
new revision: 1.286; previous revision: 1.285
done
Checking in toolkit/mozapps/extensions/test/unit/head_extensionmanager.js;
/cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/head_extensionmanager.js,v  <--  head_extensionmanager.js
new revision: 1.5; previous revision: 1.4
done
RCS file: /cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/test_bug356370.js,v
done
Checking in toolkit/mozapps/extensions/test/unit/test_bug356370.js;
/cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/test_bug356370.js,v  <--  test_bug356370.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/data/test_bug356370.rdf,v
done
Checking in toolkit/mozapps/extensions/test/unit/data/test_bug356370.rdf;
/cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/data/test_bug356370.rdf,v  <--  test_bug356370.rdf
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/data/test_bug356370_1.rdf,v
done
Checking in toolkit/mozapps/extensions/test/unit/data/test_bug356370_1.rdf;
/cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/data/test_bug356370_1.rdf,v  <--  test_bug356370_1.rdf
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/data/test_bug356370_2.rdf,v
done
Checking in toolkit/mozapps/extensions/test/unit/data/test_bug356370_2.rdf;
/cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/data/test_bug356370_2.rdf,v  <--  test_bug356370_2.rdf
initial revision: 1.1
done

Comment 26

[mey.wer]

Could someone *explain* me, how to fix the bug? 
If there is given a solution here (semms so, cause status resolved fixed), I don't understand. (Will there be a general solution in firefox 2.0.0.14? (and when will that be?))

BTW, could someone comment this?
> searching the web, I found a hint to start firefox on command line by
> # firefox -unlock-item "GUID" 
> but what i have to put for GUID and if I have to do this as root or as user I
> don't know.

[and maybe also this?
Why mozilla gives such strange names to the
default-user-profile-folders??? (like a4uuokr7.default for me)]

Comment 28

[Tony Chung [:tchung]]

Verified fix on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050904 Minefield/3.0pre