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.
About three weeks ago GitHub removed a bunch of links to a repository's 'downloads' section replacing them with one big downloads button, which is only available to you on some pages, and instead of taking you directly to the 'downloads' page/section you now get a AJAXy popup that only displays some of the available downloads to you and provides a link to the 'downloads' section.
In my expert opinion this button sucks. It's hard to remember which pages it's available on, except for the source page so I always go there to find it, then I have to wait for a popup that I don't want to see inorder to get the link that I'm after.. another option is to correct the url in the location bar, which is the route I was taking before I finally decided to write a user script to bring the old tab back.
This is what the old 'Downloads' tab looked like:
This is what their new button looks like:
Find this user script at userscripts.org here.
I understand that they had too many links to the 'downloads' section before, but the only one I ever used was the 'downloads' tab, and it's the only one that I find myself wanting now that the old links have all been replaced with the big awful button. So I decided to write a user script to bring back the 'downloads' tab and remove the new button, here it is:
Gist 644434 embed above
Well I blame bug 604368 for bogging me down a bit this week. I lost some time dealing with crashes and trying to determine the cause at first, until I finally came across #604368. Oh well though, no hard feelings, it is called Minefield, and the changes are meant to improve performance, so I'm not upset at all. I was able to get some progress done on Scriptish still by installing the latest Firefox beta and Seamonkey beta and using those.
I also got some progress made on implementing @run-at document-start, it isn't going to be part of 0.1 I think at this point, but so far it looks promising, nothing pushed online yet though.
For a long time now both user script authors and Greasemonkey users have wanted Greasemonkey to be able to update user scripts. In absence of this feature user script authors have resorted to rolling their own code to do the updating, which has lead to a minefield of problems ranging from simple javascript errors to causing long downtimes on userscripts.org. Besides the obvious risks that third-party user script updaters have of not working, over using bandwidth, and harming the uptime of important websites, there is also a variability of design and usefulness which means it's hard for a user to know things that they should know, like:
Hopefully it's now plain to see why a user script engine must update user scripts, and yet none that I know of do. Greasemonkey for Firefox does not. Google Chrome runs user scripts natively, but also does not update them. Those two engines are by far the most popular, but there are a few others, all of which do not update user scripts..
Well late last year I started discussing this feature with Olivier Cornu for his fork of Greasemonkey which he called Webmonkey. Months later I decided to start a Greasemonkey fork of my own, which I call Scriptish. Then, as this year went by I discovered Mozilla's plans for the new Addon manager and the stars seemed to align.
So a couple of days ago I finally got around to implementing user script updating in Scriptish, and released the feature in Scriptish 0.1b4 last night; now I'd like to discuss it a little bit for those that are interested.
You may specify a URL for Scriptish to check for updates using the @updateURL metadata block key. The @updateURL must be a secure url (ie: starts with "https://"), otherwise it will be ignored.
To save bandwidth, and improve response times, you may optionally provide a ".meta.js" version of your user script as the @updateURL, which should be the same as the user script, but only containing the user script's metadata block. If you provide a @updateURL that ends with ".meta.js", then Scriptish will check then ".meta.js" file for updates, and download an update from the same url where ".meta.js" is replaced with ".user.js".
If you go to the options window for Scriptish you will see a preference which allows you to use a user script's download URL as the update URL if there was no @updateURL defined; this option is turned off by default.
If the update URL that should be used to check for updates is a userscripts.org URL, then the ".meta.js" version of the user script will be used by default.
All versions of Scriptish that provide user script updating will include a GM_updatingEnabled constant in the user script sandbox, this means that if you are a user script author that has implemented a updater for your script already, then your code can check if this variable is defined and equal to 'true' before attempting to check for updates.
A user script engine that updates user scripts has been long desired, so I'm proud to introduce the feature for the first time in Scriptish, and I hope you give it a try!
My favorite browser extension for quite a while has been Greasemonkey (GM), I loved how simple it made customizing the web with JavaScript (JS) which allows all users to both filter out the crap that site owners try to provide us (ie: ads, share links, suggested junk) and add new useful features anywhere you that wish. Greasemonkey allowed us to customize the waves as we surfed the web, as well as making a few modifications to the board, and I loved it for that.
Some problems arose with Greasemonkey though, because it was built for Firefox (FF) 1.5, and even the latest GM version (0.8.6) claimed to support 1.5, which meant that Greasemonkey the GM maintainers did not want to introduce new features that would not be available in FF 1.5, and they did not want to take advantage a of newer version, like say FF 3.0's JavaScript Modules (JSM), which would allow GM to use much less memory and improve performance when a user is using multiple windows, and on startup because less JS would need to be loaded at startup.
The good news for GM is that with the next major release, 0.9 (which contributors including myself have been working on for quite some time now) is that the minimum version of Firefox that Greasemonkey will support will be FF 3.0, which means it can now take advantage of the benefits that FF 3.0 offers, finally. The trouble I found while trying to contribute to GM is that the maintainers don't really want to alter the code base, they're actually seem to be fine with doing the minimum necessary and bug fixing for the rest of the future, at least that is how it seemed to me after writing quite a few patches which were rejected, either outright, or by degradation (meaning I would have to basically redo everything, on crappy architecture, because they've sat on their hands for so long). Patches such as using JSM, reg exp @includes, @icon, and a few more.
So the reason that I decided to bypass Greasemonkey and start working on a fork, which I now call Scriptish, is because I was tired of beating my head against a wall, I wanted to have and use the Greasemonkey that I always wanted asap, so I'm making it now. I've always enjoyed working with others, and I hope that I can convince some GM contributors to start working on Scriptish in the future.
Scriptish is a fork of GM, you can think of it as a superset of Greasemonkey, it can do whatever GM does, and more. Some of it's new features are:
Other changes include major reorganization of the internal code, using JSM, in a way that only loads code into memory that will actually be used, by loading the req'd code the first time that it is going to be used. I was also able to remove a bunch of legacy code, because Scriptish will only support Firefox 4.0 or higher for the moment.
If you'd like to give Scriptish a try, then you can download Scriptish here. If you want to get involved here are some links for you:
I hope you like it, I'll be working on it for the next few months at least, pretty hard I imagine; I'd like to make it restartless, and implement user script updates & communication asap. If you think you'd like to open it up and hack on it, then please do!!
Often, when you're using Google Analytics, you want to be able to segment by the page's title, but there is no default way to do this with Google Analytics.
Well, a couple of hours ago I started catching up on my reading in Google Reader, and I noticed a blog post from LunaMetrics titled "Showing Page Titles & URLs in Google Analytics", and that post pointed out exactly how to segment by page title.
So, I took a couple of minutes and wrote a userscript to add this dimension to the 'segment by' drop down with a userscript so that you can easily segment by page title, without having to think about how to do this. Here's the code:
This userscript is available on userscripts.org as well, here: Google Analytics Page Title Segmentation
Enjoy!
A very common question that I see asked on stackoverflow.com, the greasemonkey-users mailing list, and in #greasemonkey on freenode, is how to use third party libraries with a user script.
The common response is to use @require, but these days people want their user scripts to work on Google Chrome too, and unfortunately Google Chrome user scripts do not support a lot of the Greasemonkey metadata block, including @require.. so another method is required.
One method that has been mentioned elsewhere is to create a script element and add it to the page, and use setTimeout's to wait until the third party js, in this example jQuery, is loaded. The example in the link I provided is for Greasemonkey, but with little effort it can be made to work with Google Chrome.
This method creates script element for jQuery (or some other third party script), and appends it to the body element, and listens to the load event to figure out when the library is loaded and ready to be used.
Google Chrome does not allow user scripts to access javascript objects in the page scope from the user script's scope, so in order to use jQuery at all on Google Chrome you must load jQuery into the page scope and inject your script into the page scope. So this is what my example below does essentially, more specifically it stringifys a callback function which is called when jQuery is done loading.
There are many issues I have with my favorite site to host git repositories, GitHub, but today I decided to solve one of them.
When you are on a page in one of your project forks on GitHub for say some file in the repository, and you want to switch to see the same page for the project that you forked from, then you have a number of clicks and page loads ahead of you. My feeling is that there should be a single link that allows you to do this, and vice versa.
Most members of the userscript community already know about Anthony Lieuallen's User Script Compiler, and Gina Trapani's Greasemonkey Multi Script Compiler (GMSC) which she based on Anthony's compiler. These two compilers allow a user script author to convert their userscript in to a Firefox extension, at which point the author can add functionality/features that Firefox extensions have, and usersripts do not have. So for example they can add UI elements to the browser that work with the userscript, or read+write files from the file system, etc..
I've used both compilers in the past and I find they are very handy, especially when you want to package disparate user scripts together in a single Firefox extension, or add functionality to a existing userscript, essentially upgrading the user script.
Now, around the time that the Jetpack SDK was released last month I started thinking about how the possibility of creating compilers similar to the ones above but for making Jetpacks that use userscripts. The other goal that immediately struck me was to make a userscript manager out of Jetpack, which is an idea I know others have been thinking about, at least Tim Smart expressed the same idea in the #greasemonkey irc channel not long ago.
Well, last week I was toying around with the idea of running a userscript within a Jetpack, and I had a lot of success, because within a few hours I was able to create a Jetpack which contained a collection of userscripts and it worked perfectly!
After I accomplished this, I started thinking about a road map for these ideas, so here it is..
Here are my goals for this project:
This package has got to be dead simple to use, so that adding a userscript to a jetpack is as simple as dropping the userscript(s) in to the data folder of your jetpack, requiring the userscript package, and adding a line or two of code to your jetpack's main module which would make the jetpack aware that it has a userscript and act accordingly.
Furthermore, I want this package to be extendable so that third party's can create APIs that will be available in the userscript sandboxes. For example, a common question asked by new userscript authors is how to store data to disk in a file, which they quickly learn that they cannot do. But, when this package is complete their new option would be to write their userscript as they normally would, then if they come to the point where they want more API features than the GM_* API provides, then they will have the option to compile their userscript in to a jetpack, at which point they can start providing their userscript with more APIs that allow things such as storing data to a file on the file system.
This could be a website, command line package, or both, I don't really care at this point, but this must exist, and shouldn't be difficult once the Userscript package is complete. All that should be needed is a sparse Jetpack skeleton, which takes 1 or more userscripts and dumps them into the data folder, then creates a basic main module to run the userscripts.
Simply put this would be an alternative to Greasemonkey, maybe not quite as advanced as Greasemonkey, or with as nice a UI, but works and has all of the advantages of a Jetpack, namely you can install/update/remove without the need to restart, and takes advantage of the jetpack-core APIs which should mean that I won't have to worry as much about platform changes.
I've posted the code I was working with last week in a git repo which is available on Github here. If you'd like to help out then fork this project and start hacking.
If you would like to see the example I was working on last week, then it is available on Github as well here. This example is a remake of the BetterGWO Firefox addon that I created last year with Gina's GMSC.
If any of those goals sparked your interest then consider helping out, I would enjoy the company. Otherwise, I hope to have at least the userscript package mainly complete by the end of this month, so stay tuned.
@erikvold