Launchpad has imported 31 comments from the remote bug at https://bugzilla.mozilla.org/show_bug.cgi?id=356370.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2006-10-12T03:51:43+00:00 Mozilla-bugs-thequod 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 Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/2 ------------------------------------------------------------------------ On 2006-10-12T03:52:26+00:00 Mozilla-bugs-thequod wrote: Created attachment 242024 Seems to fix the bug Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/3 ------------------------------------------------------------------------ On 2006-10-12T03:57:01+00:00 Robert-bugzilla wrote: 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? Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/4 ------------------------------------------------------------------------ On 2007-02-18T04:00:04+00:00 Mozilla-bugs-thequod wrote: 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. Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/15 ------------------------------------------------------------------------ On 2007-02-25T20:19:53+00:00 pshaw wrote: I just upgraded to Firefox 2.0.0.2 and this bug is still present. Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/16 ------------------------------------------------------------------------ On 2007-04-09T22:55:10+00:00 Trent-icentris wrote: 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 Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/21 ------------------------------------------------------------------------ On 2007-04-09T22:56:23+00:00 Trent-icentris wrote: 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. Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/22 ------------------------------------------------------------------------ On 2007-04-28T21:32:58+00:00 tyee wrote: 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". :-) Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/28 ------------------------------------------------------------------------ On 2007-04-28T21:34:56+00:00 tyee wrote: >> This web page lists the location of the Firefox profile folder. Uggh! Here's that URL: http://kb.mozillazine.org/Profile_folder Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/29 ------------------------------------------------------------------------ On 2007-04-30T16:28:24+00:00 Trent-icentris wrote: 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. Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/32 ------------------------------------------------------------------------ On 2007-06-14T13:05:06+00:00 Thomas-bugzilla wrote: I installed Firefox 2.0.0.3 a few weeks ago and the bug was still present. Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/37 ------------------------------------------------------------------------ On 2007-08-28T06:41:24+00:00 Aleksej wrote: Can anyone reproduce this with Firefox 2.0.0.6 or 2.0.0.7, or the latest trunk build? Thanks. Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/40 ------------------------------------------------------------------------ On 2007-08-28T16:52:26+00:00 Trent-icentris wrote: 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.) Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/41 ------------------------------------------------------------------------ On 2008-01-24T05:18:40+00:00 Marcus Better wrote: I just got this on Debian icedove 2.0.0.9. Debian bug report: http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=441961 Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/49 ------------------------------------------------------------------------ On 2008-03-11T12:09:57+00:00 Dtownsend wrote: 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. Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/50 ------------------------------------------------------------------------ On 2008-03-11T19:00:35+00:00 Caillon wrote: 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. Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/51 ------------------------------------------------------------------------ On 2008-03-11T19:07:29+00:00 Dtownsend wrote: (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. Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/52 ------------------------------------------------------------------------ On 2008-03-11T20:18:40+00:00 Beltzner wrote: 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? Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/53 ------------------------------------------------------------------------ On 2008-03-11T20:53:36+00:00 Dtownsend wrote: (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 :) Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/54 ------------------------------------------------------------------------ On 2008-03-12T00:34:04+00:00 Mike Connor wrote: Dave, ETA? Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/56 ------------------------------------------------------------------------ On 2008-03-31T11:06:14+00:00 Dtownsend wrote: 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. Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/58 ------------------------------------------------------------------------ On 2008-03-31T16:33:05+00:00 Dtownsend wrote: 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. Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/59 ------------------------------------------------------------------------ On 2008-03-31T20:04:21+00:00 Dtownsend wrote: 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. Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/60 ------------------------------------------------------------------------ On 2008-03-31T20:27:07+00:00 Robert-bugzilla wrote: Comment on attachment 312742 less aggressive Looks good. It might be helpful to comment on what constitutes a badItem. Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/61 ------------------------------------------------------------------------ On 2008-04-01T09:28:28+00:00 Dtownsend wrote: 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 Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/62 ------------------------------------------------------------------------ On 2008-04-07T17:38:14+00:00 Dtownsend wrote: *** Bug 427530 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/63 ------------------------------------------------------------------------ On 2008-04-07T18:14:12+00:00 Mey-wer wrote: 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)] Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/64 ------------------------------------------------------------------------ On 2008-05-06T14:59:42+00:00 Dtownsend wrote: *** Bug 432386 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/72 ------------------------------------------------------------------------ On 2008-05-09T23:34:25+00:00 Tchung-mozilla wrote: Verified fix on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050904 Minefield/3.0pre Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/73 ------------------------------------------------------------------------ On 2008-06-27T12:13:59+00:00 Dtownsend wrote: *** Bug 361358 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/86 ------------------------------------------------------------------------ On 2008-08-05T13:01:33+00:00 Dtownsend wrote: *** Bug 431324 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/firefox/+bug/65609/comments/87 ** Changed in: firefox Importance: Unknown => High -- "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 member of Registry Administrators, which is the registrant for Debian. _______________________________________________ Mailing list: https://launchpad.net/~registry Post to : [email protected] Unsubscribe : https://launchpad.net/~registry More help : https://help.launchpad.net/ListHelp
