"installLocation has no properties" error in nsExtensionManager.js during install/update of extensions

Bug #65609 reported by Daniel Hahler on 2006-10-12
40
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
High
firefox (Ubuntu)
High
Mozilla Bugs
firefox-3.0 (Ubuntu)
High
Unassigned
thunderbird (Debian)
Fix Released
Unknown

Bug Description

Binary package hint: firefox

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 will be fixed for Firefox 3, according to comments upstream.

WORKAROUND/FIX from comment:
Delete (or better, rename/backup) the file extensions.rdf (from the profile folder). Firefox will recreate it when it is next started.
This solved the problem for me. No need to create a new profile.

Daniel Hahler (blueyed) wrote :

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

Created attachment 242024
Seems to fix the bug

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?

Changed in firefox:
status: Unknown → Unconfirmed

I can confirm this with the latest Firefox package.
It's really annoying, because I can't install any extensions.

Edit/Update: Manually applying the referenced patch fixes this.

Daniel Hahler (blueyed) wrote :

See the upstream bug report. They say it's due to a previous bug.

I've sent them the requested files, but no answer yet.

I've even ended up with some extensions in the state "get updated/removed/installed after Firefox has been restarted", but they did not change after restart.

So I removed my "extensions" directory and re-installed the extensions I want (and discovered some new ones :))

I don't need the patch now anymore.

Seems like there's been some internal corruption.

doclist (dclist) wrote :

Delete (or better, rename/backup) the file extensions.rdf. Firefox will recreate it when it is next started.

This solved the problem for me. No need to create a new profile.

Alex Muntada (alex.muntada) wrote :

Confirmed: remove "extensions.rdf" and then it works.

luke0123 (mark-funo+ubuntu) wrote :

i received the same error. i have suse 10.1 and firefox 2 installed. here is my error log.

------------------
Error: installLocation has no properties
Source File: file:///usr/lib/firefox/components/nsExtensionManager.js
Line: 3849

---------

what to do?

Trent Larson (larsontrent) wrote :

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

I still get the problem. Any suggestions?

Alex Muntada (alex.muntada) wrote :

Make sure you remove "extensions.rdf" (it must exist under your firefox profile directory):

$ find ~/.mozilla/firefox -follow -name extensions.rdf

frans (frans-mailinator) wrote :

After removing "extensions.rdf" I was able to install an extension. After a restart of Firefox I got the same error again when trying to install another extension. So, for me this wasn't a permanent solution.

Changed in firefox:
assignee: nobody → mozillateam
Changed in firefox:
status: Unconfirmed → Needs Info

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.

Changed in firefox:
importance: Undecided → Medium
status: Needs Info → Confirmed
David Farning (dfarning) on 2007-02-24
Changed in firefox:
assignee: mozillateam → mozilla-bugs

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

Alexander Sack (asac) wrote :

daniel, do you still possess files you sent to Robert (from bugzilla)? Maybe attach them if you have no privacy concerns about them.

Alexander Sack (asac) wrote :

needs info, because we cannot reproduce. Low importance, becase other than a spurious message there appear to be no bad side effects of this

Changed in firefox:
importance: Medium → Low
status: Confirmed → Needs Info
Daniel Hahler (blueyed) wrote :

I've forwarded the mail with the files to Alexander.

Maybe someone who is still experiencing this, should do alike and send him the required files (see comment#2: https://bugzilla.mozilla.org/show_bug.cgi?id=356370#c2)

Alexander Sack (asac) wrote :

for the log: waiting for regenerated/fixed extensions.rdf

Created attachment 261070
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

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.

Well, if you need more info, you'd need to install Ubuntu 6.10.

It happened to me on 2 of my PC's, running Ubuntu Linux.

At first, there was no effect, since after the message everything was installed correctly, but now nothing installs.

There are a lot of posts relating this problem around the Web. The thing is, that most posters didn't check the Error Console, so they didn't write about the InstallLocation message.

Let;s hope it will get solved soon.

Regards,
Dotan Mazor

dsp76 (thedsp76) wrote :

The problem is still available in Firefox release 2.0.0.3 on Ubuntu 6.10. I use the Profile shared between Windows and Linux. Its about the InstallLocation message.

dsp76

dsp76 (thedsp76) wrote :

Sorry, there are a lot side effects, as the extensions don't appear / run anymore... (like del.icio.us, adblock plus, weather fox and other extensions just disappear from the userinterface...
Tell me what information / files you need and I send it to you.

If you're talking to me, then I could use any information you have, but I
don't know what files I need. I've attached the contents of my extensions
directory onto the following bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=356370

I appreciate any suggestions. Thanks!

On 4/15/07, dsp76 <email address hidden> wrote:
>
> Sorry, there are a lot side effects, as the extensions don't appear / run
> anymore... (like del.icio.us, adblock plus, weather fox and other
> extensions just disappear from the userinterface...
> Tell me what information / files you need and I send it to you.
>
> --
> "installLocation has no properties" error in nsExtensionManager.js during
> install/update of extensions
> https://bugs.launchpad.net/bugs/65609
> You received this bug notification because you are a direct subscriber
> of the bug.
>

dsp76 (thedsp76) wrote :

Hi,
no I'm adding infos to this bug, I also experience it.

I found out, that in my case using Firefox across Windows and Linux with the same profile is causing the bug. Everytime after I used Firefox in WinXP, the extensions.rdf is altered and Firefox under Ubuntu gets problems. After deleting extensions.rdf, its working again under Ubuntu.
However, this looks like the Windows and the Linux version of Firefox is treating this file differently. I use Firefox 2.0.0.3 in both cases.

KP

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

tyee (tyee77) wrote :

I wanted to add to this discussion that I encountered this error as well with Firefox 2.0.0.3 (latest to date) in Mac OS X 10.4.9.

I discovered that, when I get the error, if I restart Firefox and re-try to install an extension that I have success. But, upon trying to install another extension, I get the error again. So, at that point, I could get around it by restarting each time.

Next, I tried renaming "extensions.rdf" and letting Firefox re-create it. After doing this, I no longer get the error message!! (Of course any previously disabled extensions were re-enabled--a tolerable trade-off!)

Hello,

In continue to tyee's message, I have renamed extensions.rdf, and it indeed solved the problem.

Oddly enough, the original file and the new file, have the same permissions.

System: Ubuntu Feisty on GNU/Linux

Kudos!
Dotan Mazor

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.

Prem Rara (fortran01) wrote :

Renaming extensions.rdf works! (e.g. mv ~/.mozilla/firefox/{profile}/extensions.rd extensions.rdf.orig)
System: just upgraded from Ubuntu Dapper Drake (6.06.1 LTS) to Edgy Eft (6.10)

dsp76 (thedsp76) wrote :

Hi Tyee,
I don't agree with the statement that its a tolerable trade-off... maybe until the bug is fixed ;-)
"Of course any previously disabled extensions were re-enabled--a tolerable trade-off!"

It's happening everytime I use Firefox with the same profile under Windows between my Linux sessions. Both RFD files differ from each other (before Windows access and after). So something seems to be broken with the interpretation of the rdf file... Windows and Linux have differences in handling this file.

dsp76

On Fri, May 04, 2007 at 10:39:14AM -0000, dsp76 wrote:
> Hi Tyee,
> I don't agree with the statement that its a tolerable trade-off... maybe until the bug is fixed ;-)
> "Of course any previously disabled extensions were re-enabled--a tolerable trade-off!"
>
> It's happening everytime I use Firefox with the same profile under
> Windows between my Linux sessions. Both RFD files differ from each other
> (before Windows access and after). So something seems to be broken with
> the interpretation of the rdf file... Windows and Linux have differences
> in handling this file.
>

OK, can you please post the differences between config file after a run
on windows (doing nothing, just starting and stopping) and another run
on linux?

 - Alexander

dsp76 (thedsp76) wrote :

Hi,
found a possible reason for that broken extensions.rdf file:
I found out that there was one extension, not installed through Firefox! It came with GMX Netphone (http://faq.gmx.net/dsl_telefonie/gmx_netphone/kopie_von_fragen_zu_softphone_2_0/1.html) and could neither be removed not controlled from within firefox extensions manager! Seems a bit strange... it could also not be found in the extensions directory, don't know where the netphone saved this extension.
When I removed the GMX netphone, the extensions.rdf didn't get corrupted anymore by using the same firefox profile with windows and linux. However, I will try to recreate the broken extensions.rdf to find out the failure.
From my view, firefox should not allow any other software that will be installed to register extensions. Isn't that somehow also a security risk? Firefox asks always, when I try to install an extension from a not known site, but when a program on my computer adds an extension from the background, Firefoy doesn't ask me?

dsp76

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

Alexander Sack (asac) wrote :

this bug has a duplicate who confirmed the workaround. We should try to eval, then push upstream.

Changed in firefox:
status: Needs Info → Confirmed

I had the same installLocation problem, unable to install new extensions, and removing my extensions.rdf fixed the problem.

Oddly enough, I noticed a side effect: switching the UI from English to German.
I installed Ubuntu in German but for some reason Firefox was in English, maybe because the profile comes from a distro that I installed in English .

Here is the chronology of what I did :
1) Ubuntu in German, Firefox in English
2) I try to install an add-on https://addons.mozilla.org/en-US/firefox/addon/1916
3) I get the installLocation error
4) I look up and find the trick on this page
5) I close Firefox
6) I delete extensions.rdf
7) I restart Firefox
8) I install the add-on successfully
9) I restart Firefox
10) I notice that Firefox's menus look a bit unfamiliar. Indeed, they are in German instead of English

I don't mind having Firefox in German, it's better, but I find it surprising, maybe the removal trick has some side effects.

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

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

ozman (barretosborne) wrote :

I can not find extensions.rdf so I just deleted my entire extensions folder in the firefox folder. I then restarted firefox like was said and I still can't get my add-ons to work. What do I do??

If you have indeed deleted the "Extensions" folder, you have deleted all of
your addons that were inside it! If so, you'll need to re-install each
addon! If your operating system is Windows XP, here is the usual location of
the "extensions.rdf" file and the "Extensions" folder that you appear to
have deleted:

C:\Documents and Settings\<your user name>\Application
Data\Mozilla\Firefox\Profiles\<your profile folder>

(If you have a different operating system, see this link:
http://kb.mozillazine.org/Profile_folder_-_Firefox)

On 10/27/07, ozman <email address hidden> wrote:
>
> I can not find extensions.rdf so I just deleted my entire extensions
> folder in the firefox folder. I then restarted firefox like was said and
> I still can't get my add-ons to work. What do I do??

Alexander Sack (asac) wrote :

not a firefox bug ... at least since firefox 2 is final the extension manager shouldn't have any of these issues.

Changed in firefox:
status: Confirmed → Invalid
Arun (arunmarjun) wrote :

Actually, I beg to differ, it is. I am still seeing it and having to apply the patch everytime i update firefox from update-manager. I initially had feisty and upgraded to gutsy. The installation is about 8 to 9 months old.

Arun (arunmarjun) wrote :

This happens to me everytime I update firefox through the update manager. Before, I used to get this error, I would go ahead and do the manual fix. But now, I dont see that error anymore, but I still have to go and add the code suggested by daniel. Just now, something wierd happened. I wanted to provide you with any errors printed in the error console, so I closed firefox, went back the commented the line added, and started firefox again. Surprisingly, everything is working. I have no clue as to whats causing the error, why it happened in the first place, why adding the code fixed it, and why its still working even after I commented the change.

I am running, Ubuntu 7.10 with all the latest updates as of 11/27/07, firefox 2.0.0.10.

Changed in firefox:
status: Invalid → Confirmed
Arun (arunmarjun) wrote :

Well, another observation. As I mentioned before, firefox seemed to keep the add-ons even after I commented the change, but just a while I decided to give firefox 3 beta a try. I downloaded the beta nightly build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ and ran it. It had the same kind of error "installLocation is null". (firefox 3 is great by the way). I closed firefox 3 and started 2.0.0.10 again and this time none of the extensions showed up. they showed up after I added the code fix in nsExtensionManager.js though.

Note: firefox 3 beta has the code to check if installLocation is null or not is missing Line no 3606

S Matthews (maxtime07) wrote :

SUCCESS ;-) I sooo appreciate you guys, especially doclist who 's suggestion worked perfectly for me :-)

"Delete (or better, rename/backup) the file extensions.rdf. Firefox will recreate it when it is next started.

This solved the problem for me. No need to create a new profile."

I just got this on Debian icedove 2.0.0.9.

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

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.

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.

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

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?

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

Daniel Hahler (blueyed) on 2008-03-11
description: updated
Daniel Hahler (blueyed) wrote :

Marking this high, because it seems to have an impact on upgrades and Ubuntu is affected.

Changed in firefox:
importance: Low → High
status: Confirmed → Triaged

Dave, ETA?

Changed in thunderbird:
status: Unknown → New
Changed in firefox:
status: New → Confirmed

Le mercredi 12 mars 2008 à 10:07 +0000, Bug Watch Updater a écrit :
> ** Changed in: firefox
> Status: New => Confirmed
> je ne comprends rien, je parle français

Created attachment 312699
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.

Created attachment 312742
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.

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 on attachment 312742
less aggressive

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

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

Changed in firefox:
status: Confirmed → Fix Released

*** Bug 427530 has been marked as a duplicate of this bug. ***

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

Alexander Sack (asac) wrote :

firefox 3 is already fixed.

Changed in firefox-3.0:
status: New → Fix Released
Alexander Sack (asac) wrote :

aeh, already fix committed.

Changed in firefox-3.0:
status: Fix Released → Fix Committed

I just installed Ubuntu 8.04 and it came with Firefox 3.05b... I downgraded it to Firefox 2.0.0.14 and I'm getting this error... I had installed 4 plug-ins on Firefox 3.0 and I couldn't install most of the developer's plug-ins (that's why I decided to downgrade it...)...

Right now I can't move on :'( I can't install anything and the previous downloaded plug-ins are listed there...

please, let me know a work-around...

Thanks

szako (sacoka) wrote :

+1

I experience exactly the same

Gene Mosher (genemosher) wrote :

Brand new install of Hardy Heron Kubuntu on a new hard drive and I have this same problem when trying to install ANY extension under FireFox 2. I'd like to see someone on the FireFox team acknowledge the seriousness of this bug and fix it.

installLocation has no properties
file:///usr/lib/firefox/components/nsExtensionManager.js Line 7647

This line is in the section
* Gets an URL to a theme's image file
_getThemeImageURL: function(item, fileName, fallbackURL) (
   var id - stripPrefix(item, Value, PREFIX_ITEM_URL);
   var installLocation = this._em.getInstallLocation(id); <<< this is line 7647

John Stevenson (verb-adverb) wrote :

I had exactly the same problem as Gene Mosher, in that I wanted to revert to FF2 to continue using various extensions that are not yet compatible with FF3.

This was on a box-fresh install of Ubuntu Hardy.

I had no extensions.rdf to delete

I tried the patch, but that just moved the problem further down to line 7647.

Then I found this thread, among others:

http://ubuntuforums.org/showthread.php?t=770462

Deleting /home/$username/.mozilla/ worked for me.

Mélodie (meets) wrote :

Hello,

I had Firefox 3 installed, and I preferred to install Firefox-2, the 2.0.0.14 version, in order to use some plugins that are not yet available with the 3 bêta 5 version of Firefox. So I did have a .mozilla directory in my home at this point.

I also found the same bug, and then found the thread here by searching on the web with the error message. I didn't get result by putting firefox profile away, but instant result came after putting the whole ~/.mozilla directory away. After restarting Firefox I could also add one more extension with no further problem.

*** Bug 432386 has been marked as a duplicate of this bug. ***

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

Alexander Sack (asac) wrote :

I think we should consider the trunk patch for the 1.8 branch here.

Trunk patch from mozilla-bug #356370: https://bugzilla.mozilla.org/attachment.cgi?id=312742

Alexander Sack (asac) wrote :

... according to https://bugzilla.mozilla.org/show_bug.cgi?id=356370#c22 upstream might want that 1.8 patch.

Desprado (ritchdavis) wrote :

I resolved this trouble by performing a complete uninstall of Firefox using the package manager. After removal I renamed the .mozilla folder, rebooted, then reinstalled Firefox 2 from "Add/Remove..." Firefox now works exactly as it should.

ozzfan1976 (surja-gain) wrote :

I uninstalled Firefox 3 from Synaptic Manager and installed Firefox 2. After this I could not install add ons - an error message showed "installLocation has no properties". Following the advice on this page, I deleted the ".mozilla" folder from my Home directory and restarted Firefox. The problem was solved and I can install the add-ons again.

Keith Hughitt (keith-hughitt) wrote :

The workaround/fix mentioned in the bug description worked for me with Swiftweasel 2.0.14.

Philipp Kern (pkern) wrote :

This is still a problem on fresh installations of Ubuntu Hardy, with Firefox 2 installed in addition to Firefox 3.0.

Philipp Kern (pkern) wrote :

Deleting extensions.rdf fixed it. Might be a problem that firefox-3.0 was invoked before and thus created files not compatible with firefox-2?

On Mon, May 26, 2008 at 10:01:34AM -0000, Philipp Kern wrote:
> Deleting extensions.rdf fixed it. Might be a problem that firefox-3.0
> was invoked before and thus created files not compatible with firefox-2?
>

Its a problem of firefox 2 ... it should be more graceful about what
info is available for extensions.

 - Alexander

r2d2 (r2d2-c3p0) wrote :

workorround?

firefox -ProfileManager ( create a profile for firefox like "FF3")

sudo su ( and then:)

cd /usr/bin/

mv firefox-3.0 firefox-3.0.orig

rm firefox

echo -e '#!/bin/bash '"\n/usr/bin/firefox-2 -P default" > firefox

chmod 755 firefox

echo -e '#!/bin/bash #"\n/usr/bin/firefox-3.0.orig -P FF3" > firefox-3

chmod 755 firefox-3

r2d2 (r2d2-c3p0) wrote :

sorry. not
echo -e '#!/bin/bash #"\n/usr/bin/firefox-3.0.orig -P FF3" > firefox-3
but:
echo -e '#!/bin/bash '"\n/usr/bin/firefox-3.0.orig -P FF3" > firefox-3

Alexander Sack (asac) wrote :

On Wed, Jun 04, 2008 at 07:08:25PM -0000, r2d2 wrote:
> sorry. not
> echo -e '#!/bin/bash #"\n/usr/bin/firefox-3.0.orig -P FF3" > firefox-3
> but:
> echo -e '#!/bin/bash '"\n/usr/bin/firefox-3.0.orig -P FF3" > firefox-3
>

Hey, if you post such workarounds, please never ever advise users to
put that in a system location. they can create such wrappers in
$HOME/bin or /usr/local/bin/ if they want, but please dont encourage
them to change what was shipped by packages by hand.

Now, pleaes repost your instructions with better paths.

 - Alexander

r2d2 (r2d2-c3p0) wrote :

O.K., O.K., O.K. ...

I will correct myself :-)

echo -e '#!/bin/bash '"\n/usr/bin/firefox-3.0.orig -P FF3" > /usr/local/bin/firefox-3

&&

echo -e '#!/bin/bash '"\n/usr/bin/firefox-2 -P default" > /usr/local/bin/firefox

Then we should put "/usr/local/bin/firefox" into /etc/alternatives... but no alternatives for firefox there... and noone have /usr/local/bin as first in $PATH - only "/usr/local/bin/firefox" starts this wrapper.

So: I think, it is better to put this in /usr/bin/firefox and 'hope & pray', that the next package version can solve the problem (if so, you can replace "firefox-3.0.orig", if not, you get the old terror back)

R2-D2

*** Bug 361358 has been marked as a duplicate of this bug. ***

*** Bug 431324 has been marked as a duplicate of this bug. ***

Micah Gersten (micahg) wrote :

This was released with Firefox 3.0

Changed in firefox-3.0 (Ubuntu):
importance: Undecided → High
status: Fix Committed → Fix Released
Micah Gersten (micahg) wrote :

Firefox 2 is EOL

Changed in firefox (Ubuntu):
status: Triaged → Won't Fix
Changed in firefox:
importance: Unknown → High
Changed in thunderbird (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.