Dynamic Greasemonkey Scripts

A friend and I recently did some work for a client creating a small Greasemonkey script.  Greasemonkey is a nifty little tool that lets you run custom scripts on webpages of your choosing.  These scripts are written in JavaScript and are local to your machine, not served up from some remote server.  They let you make changes to web pages on the fly, as if you got to write your own JS for that page.

The GM script had to work for Firefox and Chrome.  Firefox requires an extension, whereas chrome recognizes a GM script automatically.  The task seemed pretty easy.  We needed to dynamically create a GM script to be installed on the user's system.  All a GM script really needs is some JS with a few special comment fields at the top of the script, and you're ready to rock and roll.  No biggie I thought, I'll just hack up a quick PHP script to spit back the custom JS...no dice.  It turns out that the GM plugin in Firefox and Chrome's auto-detection require that the file name end in .user.js.  Well, this posed a problem.  I need a file ending in .user.js to be served up by the web server, but I needed it to have dynamic content.  I can't write the dynamic parts in JS since a GM script doesn't actually get executed by the browser when served, it get's preempted by the plugin/module, and offered for install as a user script.  I couldn't make a PHP script spit back the GM script because the plugins would refuse to install something ending in .php.

The solution we ended up with was that we added a special rule to run the GM script through PHP before serving it.  We developed on nginx, and came up with the following config rule:

location ~* script_name\.user.\js$ {
    if (!-f $request_filename) {
        return 404;
    }

    fastcgi_pass 127.0.0.1:9000;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include /etc/nginx/fastcgi_params;
}

Unfortunately, our client uses apache, so here's the config rule we came up with:

<FilesMatch "script_name\.user\.js">
  AddHandler php5-script .js
  AddType text/javascript .js
</FilesMatch>

We had a second challenge ahead of us.  The default MIME type for a file processed by PHP is text/html, but the browsers expected type text/javascript for GM scripts. Our quick and dirty solution for testing was to user PHP's header function to set the content type:


header('content-type:text/greasemonkey');

The last hurdle we had to face was a browser compatibility issue.  We needed to pass information to the backend via a query string so we could actually make the content dynamic.  That query string gets tacked on to the end of the URL, meaning we now had a URL like http://www.example.com/script_name.user.js?param=foo.  Unfortunately, the Firefox plugin didn't like that very much.  It seems the plugin just looks for a .user.js at the end of the entire URL, query string and all, to determine if it's a GM script.  Time for another hack: just tack the script's file name as the last part of the query:

http://www.example.com/script_name.user.js?param=foo&gm=script_name.user.js

It didn't take too much time for us to figure out this workaround, and it's certainly not the cleanest solution, but it was a good learning experience.  It seems Greasemonkey could really benefit from having it's own MIME type, say "text/greasemonkey".  That would allow the broswer plugin/module to recognize a GM script by it's content type instead of only by some file extension or string at the end of the URL, as well as allowing for easy, dynamic generation of a GM script, using something like PHP's header function.

Comments

Post a Comment

Popular posts from this blog

Welcome!

I guess I'm only welcoming myself for now, since nobody else reads this (yet).  It's about time I got one of these things going.  I still have no idea what direction this thing will take, but I might just let it steer itself and enjoy the ride.  I figure there will be a fair amount of techie stuff here, mostly revolving around C, embedded programming and maybe some PHP extensions.  Hobbies include brewing, surfing, working on cars and houses, so some of that will likely pop up.  And I like to follow current events, politics and economics, but on a somewhat light level, so you might see the occasional post about that.  I like to ponder math, religion, philosophy, literature and linguistics, so a bit of that might come up too.  Basically, nothing is off limits, but I'll try to keep it to polite dinner table conversation.  So check back from time to time, and hopefully you'll find something interesting.
Read more

Easier sed than done

sed seems to be one of the least used, and possibly most hated of the standard Unix utilities.  But honestly, I think it gets a bad rap.  Sure, it seems to have a steep learning curve, but vi did too when I first started.  It's just that I use vi heavily, on a daily basis.  Not so much sed.  I must admit, my sed skills are sketchy at best.  I can only produce meaningful sed scripts with a good reference, but it's often the best tool for the job.
Read more

Good Preprocessor Usage

I was digging through some code and came across the following preprocessor construct: #if FOO == 0 void foo(int bar) { #endif #if FOO != 0 void foo(float baz) { #endif As a general rule, conditionally-compiled code makes the hairs on the back of my neck stand up, but given that this is code for embedded systems, and the same basic code runs on a number of different hardware platforms, I understand that it is sometimes a necessary evil.  The problem is, people don't always treat preprocessing directives as what they really are: code.  They're instructions processed by a computer, and deserve the same good coding practices that one would apply to the rest of their source code.  Preprocessor code may actually deserve more attention to best practices due to the difficult nature of debugging it.  Taking the above as a case study, here are a few thoughts on how to improve this:
Read more