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.
Related
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).
Fine uploader is 400kb of javascript code and 140kb minified. Since I am not using the UI and only using the API, I would like to build the library without the integrated interface (and hopefully get a smaller lib consequently). Is this possible?
Could not find this in the downloads section.
I've also setup the build environment and built the package myself, but all the files in the _dist dir seem to be bundled with the UI.
Fine Uploader is only 40 kB gzipped, which is compression that pretty much every web server already utilizes. The build is not currently setup to create a bundle without the UI. If you'd like to create such a build, the modules.js file will need to be modified. One place to start would be with a copy of the fuTraditional module sans the #fuSrcUi module. Then, a corresponding entry would need to be added to the concat.js build file. This doesn't seem worth it to save a few kB in my humble opinion, but it's all very possible.
If you're interested in a much more modular upload library where almost every feature is represented as an optional standalone module, take a look at Modern Uploader, which I am slowly developing as time allows. Feel free to open up issues in the repo if you have any questions regarding the future of that product.
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 need to be able to compile firefox and bundle it with a few extensions so when people download it the extensions are already there.
I was wondering if anyone can point me to some documentation. I have been searching for hours and can't seem to find anything like that.
Thanks,
Sebastian
If you don't need to specifically 'compile' Firefox and are using Windows, you can create a simple batch (.bat) file to execute the Firefox installer and then the extensions installers in order. Alternatively, you can also use a Powershell (.ps1) script.
you might want to check out CCK or something like it.
It's a matter of copying the extensions contents to the extension guid directory of FireFox. First unzip the extensions files (xpi files are just a normal zip files) then copy them.
You can do that automatically by writing simple shell scripts for Linux/Unix/Mac, or, batch files for Windows XP and PowerShell for Vista (as John Dunagan mentioned).
Check the forth post in the following thread
http://forums.mozillazine.org/viewtopic.php?f=7&t=586672&start=0&st=0&sk=t&sd=a
I don't see a need for recompiling it.
Just create an install procedure (a script actually), which is gonna install firefox first and then the extensions afterwards.
Recompiling won't help at all. The extensions aren't compiled into Firefox, because doing so would make Firefox have to be recompiled every time an extension is installed. Just follow the above answers to automatically install the extensions.