I'm doing this tutorial on how to setup your environment in creating a firefox extension and I don't understand this part:
Pointing to an extension
In your development profile folder, you will find a folder named extensions. In it, you will have code for all your installed extensions. Instead of placing your code there, you can create a pointer file. Do that by creating a file with a unique name for you (this will have to be the same as you chose for your em:id value in your install.rdf file – more on that below).
This part can be found in this link: How to develop a Firefox extension
I am doing it in Ubuntu. Is this the same as creating a symbolic link? I am confused on this part.
No, not all operating systems that Firefox runs on have symbolic links - so a different mechanism had to be invented. You need to create a text file with the name matching the extension ID and with the path to the extension directory as its contents. A symbolic link with the same name pointing to this directory should do just as well but might be less resistant if the extension manager decides that an update is available for your extension (update installation will remove the symbolic link and replace it by a regular extension install, not sure whether this happens with a text file as well).
Personally, I realized that properly installing extensions produces more consistent results - you don't get the ugly situation where some parts of your extension are updated while others are not. This is why I wrote Extension Auto-Installer (note: this is self-promotion), it simplifies the installation process a lot - especially when you are developing a restartless extension.
Related
I'm creating "JSON fragment extensions" for Windows Terminal in my code, to create some "auto-generated" Windows Terminal profiles.
In the official docs, JSON fragment extensions in Windows Terminal, there are 2 locations recommended for storing fragments (if your application is not a Microsoft Store app):
For applications installed from the web, there are 2 cases.
The first is that the installation is for all the users on the system. In this case, the JSON files should be added to the folder:
C:\ProgramData\Microsoft\Windows Terminal\Fragments\{app-name}\{file-name}.json
In the second case, the installation is only for the current user. In this case, the JSON files should be added to the folder:
C:\Users\<user>\AppData\Local\Microsoft\Windows Terminal\Fragments\{app-name}\{file-name}.json
This seems straightforward enough, but there's some other documentation that describes the actual settings.json file location:
The path for your Windows Terminal settings.json file may be found in one of the following directories:
Terminal (stable / general release): %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json
Terminal (preview release): %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminalPreview_8wekyb3d8bbwe\LocalState\settings.json
Terminal (unpackaged: Scoop, Chocolately, etc): %LOCALAPPDATA%\Microsoft\Windows Terminal\settings.json
So, to be clear, these paths are not important if I'm creating profile fragment files, right? I don't need to choose a different path (%LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe vs %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminalPreview_8wekyb3d8bbwe vs %LOCALAPPDATA%\Microsoft\Windows Terminal) for the Fragments files because Fragments will always be loaded from C:\Users\<user>\AppData\Local\Microsoft\Windows Terminal\Fragments etc?
Disclaimer: I work for Microsoft.
So, to be clear, these paths are not important if I'm creating profile fragment files, right?
Correct! The locations Terminal looks for fragment files are well-defined and durable across different versions.
I wrote some code that manually takes a XPI that was already installed from one Firefox profile, and set's up the xpi to be manually set up on a different profile or computer entirely.
So the I set everything up fine within the extensions.sqlite Database that is within the user profile folder. I can even rename the extension on the fly when I move the xpi itself into the extension folder.
Here's my question: When I extract the XPI, there is a file called 'harness-options.json'. Within that file there are two variables, docsSHA256 and jsSHA256.
These to hash variables must be based on the extension in some way, but I am not sure how exactly.
Could anyone point me in the right direction as to how firefox generates these hash codes?
Thanks.
Firefox does not generate these hashes at all. It is the Add-on SDK which does. The Firefox extension manager does not care about harness-options.json at all. The SDK loader in turn, does care about harness-options.json a bit, but doesn't do anything with jsSHA256 or docsSHA256 at the moment. Other tools, such as the validator that runs when you upload something to addons.mozilla.org, do care about jsSHA256 at least.
It should be noted that add-ons not using the SDK do not (normally) contain a harness-options.json file at all.
There will be one jsSHA256 per module lib/, e.g. one for main.js and so on.
docsSHA256 for main.js will be generated from README.md when the SDK builds the XPI. Apparantly, README.md is not packed into the XPI. For all other modules it appears docsSHA256 appears to be null.
The code in question lives in manifest.py.
In the end you shouldn't mess with the XPI (other than repacking an unpacked extension) and/or extensions.sqlite at all. Especially the latter isn't meant to be modified externally.
Just drop the your XPIs files in the corresponding extensions/ folder of the profile and the Add-on manager will automatically pick them up the next time you start the browser.
Developing an extension for Mozilla Firefox I wonder if there is an "easier way" to what I do right now. Currently I do:
Create a folder - in which to develop - for example myextension
Inside this folder: Create and Edit the Files (like install.rdf, chrome.manifest, xul files. Basically all the other structure of a Firefox extension (no problem here))
Zip-compress the content of the myextension to a ZIP-file (i.e. named myextension.zip)
Rename myextension.zip to myextension.xpi
Install the xpi-file-firefox-extension then in firefox
Restart Firefox
Test the extention
After each edit to the codebase of the extension I need to undergo the process of 3. zip-compress, 4. Rename, 5. install XPI file to firefox, 6 restart browser.
Of course I could automate some of this but still I wonder if there is another way to develop the firefox extension directly in the running firefox profile folder .
The extensions I know are stored in the Firefox profile folder as:
firefox/profile/extensions/nameofextension.xpi
I cannot remember well, but I think that there was a way to have the extension being stored unzipped as a folder there too? This way I would still need to restart after edits but not do all the laboursome zipping-renaming-installing.
Any ideas?
It is possible to setup a directory to "in-place-edit" a firefox extension. By this the effort between editing and testing of the Firefox-extension can be reduced.
I have found the good explanation on the blog https://blog.mozilla.org/addons/2009/01/28/how-to-develop-a-firefox-extension/
Here I want to give the principal steps necessary to achieve the "in-place-edit"
Step 1: You have to find your profile directory of Firefox.
For example in Linux this would often be often something like this:
~/.mozilla/firefox/#%#%.default/
Step 2: Go to this profile directory
Step 3: If you already have any extensions installed (like for example adblock+ or noscript), then inside this profile directory you will find a folder named extensions. If you do not have yet any additional extension installed, it might be easy to simply install any, only to have the **extensions" folder be setup for you.
Step 4: In this extensions folder you can create a new directory (let us name it "myextensions_1"), which shall contain the stuff of your plugin. This stuff would be the ordinary things like the install.rdf, chrome.manifest files and the content,skin,locale subdirectories. In effect all the stuff you would normaly zip up to become the XPI file.
Step 5. Create a file that is equal to the content of the <em:id> tag that you used in your ìnstall.rdf file. So if you used <em:id>myextensionname#author.org</em:id> you need to create a file named myextensionname#author.org. Inside this file you will write the location of the "in-place-edit-extension-folder" we created before. In our example this we would have
the file myextensionname#author.org
which contains only the text ~/.mozilla/firefox/#%#%.default/extensions/myextensions_1
Of course the text depends on the location of the folder you use for your plugin.
If you did all things correctly - and maybe double-checked with the instructions of the link above - you can restart or "newly start" firefox. The browser will ask you if you want to allow the usage of the plugin myextensionname#author.org, which you can conceed.
Now you can edit in the folder ~/.mozilla/firefox/#%#%.default/extensions/myextensions_1 and need not to worry about zipping-up -> renaming -> installing.
You simple restart Firefox and the edits to your extensions code will become available.
This will allow you swifter and faster developing "in-place".
Note: this is a shameless self-plug - I am talking about an extension I created myself.
Developing an extension in place is possible but has so many issues (mostly caching of all kinds) that it really isn't a good option. Still, you can simplify your development cycle a lot. For that you need to install the Extension Auto-Installer add-on in your Firefox. Then you can put a batch file (assuming that you are developing on Windows) into your extension directory along the lines of:
zip -r test.xpi * -xi *.bat *.xpi
wget --post-file=test.xpi http://localhost:8888/
del test.xpi
The required command line tools are all preinstalled on Unix-based systems, for Windows you can easily download them: zip, wget.
Then you will only need to run that batch file to update your extension in Firefox. If your extension isn't restartless then Firefox will restart automatically. So this replaces your steps 3 to 6.
I have installed Firefox extension by double clicking abc.xpi file. Now I want to know where those files are copied, so that I can delete them. Or any other way to uninstall an extension except by going to Addons & then uninstalling it manually. I want to uninstall it programmatically.
The files created as part of the extension installation process are stored within the Firefox profile which you were using at the time. If you aren't aware of setting up more than one profile, you're probably using the "default" one which you got when you installed Firefox. Messing around with stuff within the profile directory can be extremely unwise, but if you want to try it you might want to think about:
locating the profile directory - this will depend on your operating system, but looking under the directory specified in the environment variable USERPROFILE would be a good start
finding the id for the extension you wish to remove
removing the subdirectory corresponding to the extension id under the extensions directory within the profile
remove the reference to the extension from the extensions.ini file
possibly remove the extensions.rdf file completely, to allow it to be regenerated
I am currently unaware of an automated way of doing this from the command line, if you don't want to do it yourself, but there might be tools out there to do it for you.
I want to put my dependent files in the app directory.
I seem to remember that you can force VB6 to use the files in the local directory only.
Any hints?
You may also want to try setting up Reg-Free COM for your project. There's a freeware called Unattended Make My Manifest that will do most of the work for you.
Placing component libraries in the EXE folder (with or without .local files) can be deleterious to the hygiene of target machines too.
VB6 programs will register the components here via the self-reg entrypoint behind your back if they are not previously registered. Then if the application is moved or removed you leave the user with a broken reigistration - possibly fatal to subsequently installed applications using some of the same components. This is probably fine though for application specific components, i.e. your own DLL or OCX that will never be needed by another application.
The .local trick was really not meant for use with VB6 programs and if it is used your installer needs to be aware and properly install and register the components if they are not already on the machine. It was meant as a manual hack to get around DLL version compatibility problems on individual machines, not a deployment strategy.
Move up to SxS application and assembly manifests (Reg-Free COM and more) for a better solution. DLL/COM Redirection (.local) was a good try but it has many warts.
Clay Nichol's answer about the search order is not quite correct. That search order only applies to non-COM components. I.e. only some DLLs, and not OCXs. If you register your COM objects, they will be used from the directory where they are registered regardless of what's in the local directory, unless you use reg-free COM or a .local file.
EDIT:
MakeMyManifest is well spoken of as an automatic tool for creating manifests for VB6 projects, haven't tried it myself.
DirectCOM also has fans, again I haven't tried it.
EDIT The MMM website is down. I see here that the author was having trouble with their hosting and has provided another location to get Make My Manifest - download it here.
There is a semi-automatic technique to generate reg-free COM manifests. You can create the manifests with Visual Studio 2008 (you can use a free version like Visual Basic Express Edition). Then make a couple of edits by hand to make the manifests suitable for use from VB6. See this section of this MSDN article for step-by-step instructions - ignore the rest of the article which is about ClickOnce.
It can be sort of confusing because every version of windows, the rules change. Older versions of Windows search the path before the current directory.
A simple solution without manifests:
If your executable file is A.EXE, add a (0-byte, empty) file in the same directory named A.EXE.local -- for older versions of Windows this puts the app directory ahead of the path in the search order.
Found it myself:
Windows does look in the App Directory first:
If SafeDllSearchMode is enabled, the search order is as follows:
The directory from which the application loaded.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The current directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
If SafeDllSearchMode is disabled, the search order is as follows:
1. The directory from which the application loaded.
2. The current directory.
3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
according to : http://msdn.microsoft.com/en-us/library/ms682586.aspx
But you can redirect where it looks for .dll's using a Manifest:
http://msdn.microsoft.com/en-us/library/aa375365(VS.85).aspx