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)

x86
Windows XP
defect

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
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]
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.
*** Bug 297514 has been marked as a duplicate of this bug. ***
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.
10:30 < bsmedberg> 291807 will be solved by bug 297312 #2 10:30 < bsmedberg> no patch yet Updating dependency tree.
Depends on: 297312
Assignee: bugs → benjamin
Will be fixed by bug 297312.
Flags: blocking1.8b4+
Target Milestone: --- → Firefox1.1
Whiteboard: [does not block 1.1a] → will be fixed by 297312
Priority: -- → P2
Fixed by bug 297312 for 1.8b4.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
*** Bug 304384 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.