Closed
Bug 291807
Opened 20 years ago
Closed 19 years ago
Installing extensions by putting a GUID file in profile/extensions doesn't work with absolute paths to a different drive than the profile
Categories
(Toolkit :: Add-ons Manager, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla1.8final
People
(Reporter: asqueella, Assigned: benjamin)
References
Details
(Whiteboard: will be fixed by 297312)
I cannot register an extension by putting a GUID file with "x:\dev\myextension"
contents in [profile]/extensions/ folder. Putting "c:\dev\myextension" works.
(C: is the drive my profile is on).
The following code seems wrong:
--
function getFileFromDescriptor(locationKey, descriptor) {
var lf = Components.classes["@mozilla.org/file/local;1"]
.createInstance(nsILocalFile);
if (locationKey == KEY_APP_PROFILE)
lf.setRelativeDescriptor(getDir(KEY_PROFILEDS, []), descriptor);
else
lf.persistentDescriptor = descriptor;
return lf;
}
--
It special-cases the app-profile location to expect a relative path in the GUID
file. This means I can't install profile-specific extensions located on a
separate drive on Windows. It's a pity (I've explained why I need this in bug
291791).
It shows an error in JS console:
Error: [Exception... "Component returned failure code: 0x80520001
(NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsILocalFile.setRelativeDescriptor]"
nsresult: "0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)" location: "JS frame ::
file:///C:/PROGRA~1/Mozilla.org/FIREFO~1.EM/components/nsExtensionManager.js ::
getFileFromDescriptor :: line 373" data: no]
Source File:
file:///C:/PROGRA~1/Mozilla.org/FIREFO~1.EM/components/nsExtensionManager.js
Line: 373
Assignee | ||
Comment 1•20 years ago
|
||
Eek, this sucks on so many levels. Darin, I am seriously considering that we
need a better absolute-or-relative file descriptor code, hooked into the
directory service: patch coming shortly.
Flags: blocking-aviary1.1+
QA Contact: bugs → benjamin
Whiteboard: [does not block 1.1a]
Comment 2•20 years ago
|
||
I found this problem too. Would it not be more sensible just to use a uri in the
file descriptor (like the wiki seems to imply). That way it could be relative or
absolute.
Comment 3•19 years ago
|
||
*** Bug 297514 has been marked as a duplicate of this bug. ***
Comment 4•19 years ago
|
||
As a sidenote, this can be worked around manually by editing extensions.ini and
the GUID file after the fact. ie: if you copy the contents of x:\dev\myextension
to c:\dev\myextension, modify the GUID file to match, let the extension register
properly, then remove c:\dev\myextension and manually edit both the GUID file ad
extensions.ini to point to x:\dev\myextension, things will work.
Comment 5•19 years ago
|
||
10:30 < bsmedberg> 291807 will be solved by bug 297312 #2
10:30 < bsmedberg> no patch yet
Updating dependency tree.
Depends on: 297312
Updated•19 years ago
|
Assignee: bugs → benjamin
Assignee | ||
Comment 6•19 years ago
|
||
Will be fixed by bug 297312.
Flags: blocking1.8b4+
Target Milestone: --- → Firefox1.1
Assignee | ||
Updated•19 years ago
|
Whiteboard: [does not block 1.1a] → will be fixed by 297312
Assignee | ||
Updated•19 years ago
|
Priority: -- → P2
Assignee | ||
Comment 7•19 years ago
|
||
Fixed by bug 297312 for 1.8b4.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 8•19 years ago
|
||
*** Bug 304384 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•19 years ago
|
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•