registry team mailing list archive
-
registry team
-
Mailing list archive
-
Message #19208
[Bug 65609] Re: "installLocation has no properties" error in nsExtensionManager.js during install/update of extensions
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.
