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.
Related
I have a fairly large application (~750k LOC) that I distribute using the Package and Deployment Wizard. I fully understand that it would be nice to migrate to .NET (that ain't happening - see the code size above), and that the PDW is deeply flawed. However, for the most part I've made it work well for my end users, by customizing the Setup1 application, writing a menu-driven wrapper for the Setup application, and by running it in silent mode. (Note that the problem I'm about to describe occurred even before I started using silent mode.)
The issue I'm having is that my application requires quite a few auxiliary files, which I've added to the PDW project in the "Included files" section. When a user does a clean installation (either from scratch, or after un-installing a previous installation), everything works fine. However, if they simply run the installer to update the existing installation, the executable file and any OCXs I've updated get copied over the previous versions just fine, but my auxiliary files don't - I have to have the user manually delete them, and then the Setup1 program will re-install them as it should.
I've checked in the Setup.lst file, and all of the files are listed there, with their current date stamps. In fact, in my "BuildAll.bat" file, I do the Windows equivalent of a "touch" (copy /b "TheFile.dat" +,,) to force the date stamp to be current. However, if the file exists on the target machine, it won't be over-written even though it's older. There are no errors reported, either visibly or in the .LOG file (which is required if using the silent option).
A couple of additional points: Some of the auxiliary files are themselves VB6 applications - just the .exe files. Those do get copied correctly if they're newer than the existing files. Other than being files with internal versioning information, there's no difference between them and the other auxiliary files (which are things like media files, or text-based .txt or .dat files).
So, what's going on, and how do I fix it (besides moving to Inno or some other solution that won't work for me...)? Thanks in advance for any help!
~~
Mark Moulding
Has anyone successfully used expansion files with appcelerator? I have found the module that is supposed to let us work with them, however I am running into the problem of the .obb file being downloaded directly from the play store and then being downloaded again with the module. Aside from that I can't seem to get access to any of the files contained within the .obb using the module.
I have heard all of the woes of having a big app, so please don't just tell me to make a smaller app, my client has a large "library" that they want installed directly on the app. It consists of html files that call javascript files and images through relative paths.
Are expansion files even the way to go with this? Should I simply zip up my files and download them after, unpack them, and access them using the file system? I am just looking for a way to get these large files onto the device and access them as if they were in the resources directory of the app.
Any help would be appreciated. thanks!
I have an app that needs over 300 PNG images and text files (to populate a database with) and could not get the app small enough to put up on the Play Store. What I ended up doing was create a barebones app (enough to get the user started) then I download the files on start up. I didn't mess with zipping everything (the data is constantly being updated), but if the information you have is pretty static, you could zip it. Once the download successfully finishes and installs the data, it sets an app property (Ti.App.Properties.setInt) 0 is never ran, 1 is partial download and 2 is download is installed (you can do this however you want, but that's what I did).
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.
Have made quite a bit of progress in my quest to figuring out the Mozilla extension platform, but am still struggling with a few issues.. Hoping someone here can point me in the right direction once again :)
Ok, so here is the issue... I have been messing around with the online addon builder app here: https://builder.addons.mozilla.org/
Great, this seems to be working ok for testing simple addons. But it includes so much extra junk - stuff I am not using and don't need there.
Now when I download the .xpi file, rename it to .zip, and extract it to work on the files, when I repackage it to a zip -> xpi, Firefox tells me the package is corrupt when I try to install.
I have deduced that this is because the package is "signed" or something, and when I repackage it myself this is not happening.
Whatever. This is getting ridiculous...
So I want to use the SDK to work locally, and then just include the SDK in the directory somehow. But it looks like I need to install python and run something in order to generate some files first blah blah blah.... are you joking me? I can't just code my app, then include the SDK files?
QUESTION:
How can I create my basic addon/extension with the online Addon Builder, then edit the files locally, repackage it, and use it?
Add-ons created with the SDK currently aren't signed (see bug 613618). There are a bunch of SHA256 checksums in the package manifest but nothing is verifying them (maybe they are meant for verification by external tools, I don't know). So this is not the problem you are experiencing.
Most likely issue is that when you repacked the ZIP file you didn't keep the directory structure. The install.rdf file needs to be at the top level of the package, not in some subdirectory. You can check it with the unzip -l mypackage.xpi - it should list install.rdf without any directory name.
Generally, I would advise against manipulating the XPI files. By removing unused modules you might be able to save 100 kB in download size, most likely less - somebody installing your add-on will not even notice the difference in download size. Modules that aren't used have zero impact on performance of your add-on. But you risk removing something that is actually used, maybe in a non-obvious way. And once AMO starts repacking SDK add-ons automatically they will replace your add-on by the standard package anyway.
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.