Ever since I got my Android and installed Fennec I've wanted to add support for user scripts to Fennec. I'm happy to report that as of the last Scriptish release, you can install any user script on Fennec now!. So, now you can user script the mobile web to your heart's content. In fact, there's over 70,000 user scripts on userscripts.org alone.
For those of you that follow my blog for Scriptish news, you should know that there is a new website, scriptish.org, with a Scriptish blog.
So go to scriptish.org for your Scriptish news! though I'll probably still write about Scriptish and user scripts on this blog as well.
Well after part 1 on cfx, you should know what the cfx command line tool is, so let's see if you can build a add-on with it now. FYI, I'm going to assume you know how to use git, because if you don't then you should learn asap.
First of all you'll need to have the Jetpack SDK (aka Add-on SDK) source downloaded, I recommend getting the source from github here. I typically keep all git clones from github in a folder called "github" someplace on my HD. After you've got the Jetpack SDK downloaded, you will want to clone my simple Copy HTML add-on for Firefox.
Once you have the Jetpack source, and the Copy HTML source downloaded, navigate to the Jetpack SDK clone in a shell program and follow these instructions. You should have gotten a message that says something like "Welcome to the Add-on SDK. Run 'cfx docs' for assistance.". Running cfx docs here would allow you to access the Jetpack SDK documentation, which is very valuable, and you should get familiar with it. You can disregard the message for now though, and navigate to the Copy HTML clone in your same shell window, once you are there you can use two important commands which build your addon; the first is "cfx xpi" which will build a xpi, and the second is "cfx run" which will build the add-on temporarily and open it in Firefox instance for you to test it out. Typically you will use "cfx run" and few times, testing changes out, before finally running "cfx xpi" and distributing your add-on.
The Copy HTML add-on is a simple add-on which adds a context menu called "Copy HTML" that allows one to copy the HTML source code for the area selected. So if you highlight a blog post, and copy the html, then you will have the html source of the blog post in your clipboard, img tags, anchor links, and all.
Well give this a try, and see if you can get it to work, so that you will be ready for part 3 on using packages.
I'm starting a new series on using the Jetpack SDK, as I like to call it; you may know it as the Add-on SDK, and I wold not hold that against you ;). I won't be talking about the Add-on Builder, that's another topic that I will save for later. If you are new to the Jetpack SDK, and think you are capable of running it via command line, then I hope that this will be a good starting point for you.
So you may be asking yourself "just wtf is cfx?" at this point. Well, cfx is short for Cuddlefish executer iirc, but the point I want to make is that the name doesn't really matter, it was just a arbitrary name for the tool afaik. However, cfx is the command-line tool provided by the Jetpack SDK that will allow you to build, run, and test add-ons that you develop with it, as well as allow you to access the documentation for the Jetpack SDK, and other packages that you may be using; so the name may not be important, but the tool is. The latest version of the documentation can be accessed here, but you will be able to access the documentation of third party packages (more on what these are to come!) with the cfx command-line tool, so it's usually easier to read the documentation with the cfx tool imo.
The instructions on how to install cfx are here, and the instructions on how to use cfx are here. So I won't bore you with those details, but I suggest you read them over, so that you are ahead of the game for part 2 "how to build a addon".
Jetpack is the future. Give the old school add-ons up, it's over. Because sooner or later everything will be possible with some CommonJS style module, which would mean you'd be a fool to ignore these modules.
At the moment, I see normal restartless add-ons as those that write their own bootstrap.js file, which is a method I've been trying to help people learn to do with this series, because I felt it would be a stepping stone to converting existing old school add-ons to Jetpacks which I needed, and that other developers might need as well. Now, I can't explain why very well, but I feel that there is a freedom writing the bootstrap yourself which is very nice, and although it requires me to think about how to cleanup my code a lot more, that's something I needed.
There are serious drawbacks to building Jetpacks I think as well. Such as the file size of Jetpacks, a simple add-on which only uses a couple of the built-in modules is actually shipped with every module built-in to the add-on sdk, which means that anything you build will be at least ~250kb no matter what it does. Now that just sucks for desktop users, but for mobile users it really sucks.
Now though, I'm starting to write some common includes for my restartless add-ons, and those which I contribute to, which I'd like to share, and I'm starting to see Jetpack modules/packages being written that I want to use in my restartless add-ons. So I thought "it'd be nice to have a require() method for bootstrap.js", so I wrote a simple one:
If you copy & paste this code into your bootstrap.js file somewhere near the top of the file then you will have a require() method which will look in your add-on's "packages" folder for a ".js" file with the name you provide, if a module is not found there then the name is assumed to be a relative url.
With that you can start writing CommonJS modules which can be used by Jetpacks and even NodeJS and the like, as well as for your lean mean restartless add-ons. You can even start using Jetpack modules and other CommonJS style modules in your restartless add-on as well!
As always you can checkout Restartless Restart as a example.
If you want to use css in your restartless addon, then you have wondered what the best way to do so is. There are many options, you could create xul/html elements to inject css, or you could simply alter the style attribute of elements you care about, but the other option (and the best one imo) is to use the nsIStyleSheetService to load css.
Use the loadAndRegisterSheet() method to load css at startup, and then use unregisterSheet() to unload the file during shutdown.
You can use the bootstrap.js's "__SCRIPT_URI_SPEC__" constant to find the url of your css. For example, if you named your css file main.css and it was in a 'skin' folder in the root of your addon, then the url of the css file will be:
You must use @-moz-document however to define which content or chrome page(s) the css rules that you are defining should run on. Userstyles have the same requirements.
Here is a example where I separated the css from the bootstrap.js file for a addon called Search Tabs.
This morning I created a Jetpack module which makes it dead simple to include userstyles in a addon.
Here's a example:
In this example, the addon is loading a userstyle/css file located within it's "data" folder.
If you'd like to use this module, then it is available on github here for those of you that know how to use the addon-sdk. Otherwise, the module is also available on the Addon Builder here, and I have a example of how to use the module in the Addon Builder here. So give it a try!
For those of you that don't already know, a userstyle can be used to modify the css of any webpage (aka content) or Firefox window (aka chrome), and has been made popular by Stylish add-on for Firefox for which there is a site, userstyles.org, where thousands of userstyles can be found.
A couple of weeks ago Mozilla Labs & Twitter released a restartless Firefox add-on called "Twitter Address Bar Search", which actually did 3 main things:
Then Dietrich partly ported the address bar mods to a add-on sdk module. So I took his module, made some improvements, fixed some bugs, and whipped up a extension that does basically the same thing as the "Twitter Address Bar Search" add-on, but for Github, and made with the add-on sdk.
The "Github Address Bar Search" add-on is the same as the "Twitter Address Bar Search" add-on, except it doesn't add a Github search engine, I leave that to you.
I just wanted to make a quick update on part 2: includes, because I've written a better include() function. This one will allow you to include files at any point in your bootstrap.js file; so you no longer need to wait for the startup function to run, and you no longer need to use the AddonManager.jsm file. This is just much more simple.
Just copy & paste the script above into your bootstrap.js file and then any code executed after it can use it immediately, and with relative urls. This is why you no longer need to use the AddonManager.jsm file, and that is why you no longer need to wait to use the startup method before including helper files.
Well, I'm very proud to announce that Scriptish 0.1 has finally been released!
This is an event that has taken a long time to achieve, and I have had so much help from so many wonderful people that it has been a great pleasure to work on this project.
Greg forked Scriptish and started contributing back in Oct '10 and he's been a constant help ever since. Greg has written plenty of code, made the wiki readable, improved the usability and user experience, and no doubt has spent countless hours testing. Thank you Greg!
Olivier really showed me the way, he had forked Greasemonkey long before I ever started Scriptish, making a extension called Webmonkey which used Firefox 3 as the minimum supported version and taking advantage of the benefits that Firefox 3 had to offer. I pulled some code from Webmonkey and made Olivier the author (which he told me would be alright), but he really provided me with a proof by example of a simple idea, that a far better user script engine could be made by increasing the minimum supported version and taking advantage of the new features. Thank you Olivier!
Kris has helped out with some error handling contributions early on, answering more than a few of my questions on IRC, and for doing the last few reviews on AMO which I'm sure took some time. Thank you Kris!
Nils wrote some wonderful commits revamping the install window and really improving the UX of user scripts in the extension manager. I think these changes are the most visible to the average user, and are great improvements imo, so his help has been invaluable. Thank you Nils!
Dave is one of the developers of the new Addon Manager in Firefox, and he made a restartless extension called SlipperyMonkey (which he blogged about here) showing off a bunch of Firefox 4's new features. I've pulled a lot of this code in to Scriptish, and had the pleasure to meet Dave at the 2010 Mozilla summit in Whistler when he was showing SlipperyMonkey off, and got a change for a quick ~5min QA which proved to be most helpful to me. Thank you Dave! (and thank you David Dahl for telling me to speak with him, which I might not have done).
A community really makes all of the difference, and I've met no better. Just look at the documentation, look at the support, look at the inspiration, and look at the goals. Thank you Mozillians!
I quite honestly wouldn't have bothered spending so many unpaid hours managing a open source project without a site that helps me administrate it like Github does, because it'd just be a waste of time. Thank you Github!
@erikvold