Closed
Bug 356370
Opened 18 years ago
Closed 17 years ago
"installLocation has no properties" during install/update of extensions (line 3849/_getActiveItems)
Categories
(Toolkit :: Add-ons Manager, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla1.9
People
(Reporter: mozilla-bugs, Assigned: mossop)
References
()
Details
Attachments
(4 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
robert.strong.bugs
:
review+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•18 years ago
|
||
![]() |
||
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?
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.
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
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.
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". :-)
>> This web page lists the location of the Firefox profile folder. Uggh! Here's that URL: http://kb.mozillazine.org/Profile_folder
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.
Comment 10•18 years ago
|
||
I installed Firefox 2.0.0.3 a few weeks ago and the bug was still present.
![]() |
||
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.
![]() |
||
Updated•17 years ago
|
Whiteboard: CLOSEME 09/25
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.)
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
Assignee | ||
Updated•17 years ago
|
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox3?
Whiteboard: CLOSEME 09/25
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.
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.
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?
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P2
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 :)
Assignee | ||
Updated•17 years ago
|
Whiteboard: [swag 0.5d]
Updated•17 years ago
|
Whiteboard: [swag 0.5d] → [needs status update]
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.
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.
Attachment #312742 -
Flags: review?(robert.bugzilla)
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.
Flags: wanted1.8.1.x?
Whiteboard: [needs status update] → [has patch]
![]() |
||
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.
Attachment #312742 -
Flags: review?(robert.bugzilla) → review+
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
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [has patch]
Target Milestone: --- → Firefox 3
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)]
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
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Product: Firefox → Toolkit
Assignee | ||
Updated•15 years ago
|
Flags: wanted1.8.1.x?
See Also: → https://launchpad.net/bugs/65609
You need to log in
before you can comment on or make changes to this bug.
Description
•