Daniel Hahler Reporter
	Description • 18 years ago

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

	Robert Strong (they/them - no direct email)
	Comment 2 • 18 years ago

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?

	Daniel Hahler Reporter
	Comment 3 • 18 years ago

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.

	James
	Comment 4 • 18 years ago

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

	Trent Larson
	Comment 5 • 18 years ago

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

	Trent Larson
	Comment 6 • 18 years ago

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.

	Ray Kirk
	Comment 7 • 18 years ago

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".  :-)

	Ray Kirk
	Comment 8 • 18 years ago

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

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

	Trent Larson
	Comment 9 • 18 years ago

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.

	Thomas_H
	Comment 10 • 18 years ago

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

	[:Aleksej]
	Comment 11 • 17 years ago

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

	Trent Larson
	Comment 12 • 17 years ago

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.)

	Marcus Better
	Comment 13 • 17 years ago

I just got this on Debian icedove 2.0.0.9.

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

	Dave Townsend [:mossop] Assignee
	Comment 14 • 17 years ago

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.

	Christopher Aillon (sabbatical, not receiving bugmail)
	Comment 15 • 17 years ago

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.

	Dave Townsend [:mossop] Assignee
	Comment 16 • 17 years ago

(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.

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 17 • 17 years ago

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?

	Dave Townsend [:mossop] Assignee
	Comment 18 • 17 years ago

(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 :)

	Mike Connor [:mconnor]
	Comment 19 • 17 years ago

Dave, ETA?

	Dave Townsend [:mossop] Assignee
	Comment 20 • 17 years ago

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.

	Dave Townsend [:mossop] Assignee
	Comment 21 • 17 years ago

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.

	Dave Townsend [:mossop] Assignee
	Comment 22 • 17 years ago

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.

	Robert Strong (they/them - no direct email)
	Comment 23 • 17 years ago

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

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

	Dave Townsend [:mossop] Assignee
	Comment 24 • 17 years ago

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

	mey.wer
	Comment 26 • 17 years ago

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)]

	Tony Chung [:tchung]
	Comment 28 • 17 years ago

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