Placing a file with the name of the Lightning UUID {e2fda1a4-762b-4020-b5ad-a41df1933103} and the contents of a path to the location of the extension (f:\lightning\dist\xpi-stage\lightning) doesn't result in the extension being loaded in Thunderbird 1.1a (trunk build from 2005-06-09). I tried the following variants: - windows\style\slashes - unix/style/slashes - with the extension on the same drive - with the extension on a different drive - installing the XPI first, then replacing the local install of the XPI with the file pointer (Note: filed against Core/XPInstall Engine but we should probably have an "Extension Management" component in Core like exists in Firefox.)

Moving to Firefox/EM.

I haven't tried this with lightning but I did with DOMi and Thunderbird 20050612 and it worked fine. Steps: 1) Copy the inspector@mozilla.org directory from a Firefox installation's app/extensions directory to a new location. 2 Create a file named inspector@mozilla.org in a profile's extensions directory. 3) edit the file and point it to the directory copied in step 1. For example, c:\inspector@mozilla.org for a Windows system with inspector@mozilla.org in the root of the c drive. 4) Launch Thunderbird with the same profile as in step 2. Perhaps there is a problem with the files or the way the files are laid out for lightning but this is WFM as far as the EM goes.

Hrm. This method works just fine for me with Lightning on OS X, though. What sort of logging magic should Mike be using to gather more information?

With non-eM managed installs (e.g. registry, expanded into a directory) the EM just performs a registration of the extension if it meets the criteria for being a valid install. The js console should have a few messages as to the outcome on the first startup after the pointer file has been placed in the extensions directory.

i just realized what the problem probably is... see bug 291807.

Mike says in the initial description that he's tried with the extension on the same drive, though. Hrm again!

Perhaps another change was made, the path was incorrect in the pointer file, or any number of other things occured during Mike's testing. I suspect if the steps I outlined are followed with the current trunk using the same drive as the profile and app along with DOMi it will work. I've tried it on Linux, Win XP, and Mac OS X with Firefox and on Win XP with Thunderbird and it WFM.

hrm... it appears that if there is no chrome.manifest it won't be created properly. If the chrome.manifest is created prior to (e.g. - installing the XPI first, then replacing the local install of the XPI with the file pointer) then the chrome.manifest is good to go.

(In reply to comment #8) > hrm... it appears that if there is no chrome.manifest it won't be created > properly. If the chrome.manifest is created prior to (e.g. - installing the XPI > first, then replacing the local install of the XPI with the file pointer) then > the chrome.manifest is good to go. Nevermind.. DOMi doesn't specify any files in its install.rdf so it properly generates an empty chrome.manifest based on this

(In reply to comment #4) > The js console should have a few messages as to the outcome on > the first startup after the pointer file has been placed in the extensions > directory. Does the "should" there mean "shaver should file a bug, because putting the extension-pointer file in place with Tbird 1.1a1 on OS X doesn't show anything in the JS console, even though the extension loads and works", or instead "that would be nice and we're taking patches"?

It is more along the lines of me thinking it was outputted to the js console since I've been seeing it in my debug build. This happens before a restart so it doesn't show these messages in the js console... only in the console in a debug build. :/

Actually, I've landed my "console logging to disk" patch, so you should be able to find interesting console output at ~/.mozilla/firefox/console.log C:\Doc & Set\<user>\Appl Data\Mozilla\Firefox\console.log ~/Library/App Support/Firefox/console.log

So, I was positive that I'd tried things with the GUID file pointing to a directory on the same drive, but maybe I messed up the path. Anyway, it now works for me when the GUID file has an absolute path that points to the same drive as the application. Sorry 'bout that. Bug 291807 still exists, though. *** This bug has been marked as a duplicate of 291807 ***