Chickenfoot for Firefox: Rewrite the Web

User Interface Design Group


General How Chickenfoot differs from Greasemonkey Security Troubleshooting


Why is it called Chickenfoot?
Chickenfoot is a game that you can play with dominoes. Since Chickenfoot does much of its work by manipulating the Document Object Model, or DOM, of a web page, Chickenfoot the Firefox extension is like a toy that lets you play with the DOMinoes of the web.

What is the history of Chickenfoot?
Rob Miller (MIT) described the idea of a tool for web scripting embedded in the web browser at the CHI 2003 conference. Work began in earnest in fall 2003 when Michael Bolin took on the project for a Master's thesis at MIT. The original work used Mozilla as the environment for the tool and JNI to communicate with the Java libraries that Chickenfoot would leverage. Using JNI incurred a large overhead for the runtime of the application, as well as the pace of development. Progress improved dramatically with the discovery that LiveConnect could be used to call Java from a Mozilla extension (LiveConnect was originally designed only to allow web page authors to script Java applets).

The increasing maturity of Firefox also fueled Chickenfoot development. Though documentation about how to create extensions to Firefox was sparse, the onslaught of new extensions effectively yielded an array of small, open-source programs that revealed how to access various parts of the browser. As it appeared that Firefox was the wave of the future, and was more popular to extend, work on Chickenfoot was ported from Mozilla to Firefox in the summer of 2004.

In the winter of 2005, a web survey was done to explore how users would name textboxes in web pages. The results of this survey provided the motivation for keyword patterns, that is, patterns that identify controls in a web page with keywords that appear in the proximity of the control in the page. The results of this survey were published in a paper for an ICSE workshop on end-user programming (WEUSE): Naming page elements in end-user web automation. A nascent Chickenfoot 0.1 was released at this time.

Bolin's Master's thesis, End-User Programming for the Web, was published in the spring of 2005, and was accompanied by a release of Chickenfoot 0.2. Like the 0.1 release, 0.2 was not widely publicized as it was, in many ways, still a proof of concept that was not fit for public consumption. Bolin's thesis won the William A. Martin Memorial Thesis Prize for an outstanding Master's thesis in computer science.

Chickenfoot made the jump from "research project" to "practical toolkit" in the fall of 2005 with its 0.5 release. Version 0.5 appeared just in time for the ACM Symposium on User-Interface Software and Technology (UIST). There, Chickenfoot was presented as the main subject of the paper Automation and Customization of Rendered Web Pages, which received the best paper award for the conference.

What other systems do web automation and customization?
Here are some systems that do things related to Chickenfoot:

Note that this is probably not a complete list, because the web is such an exciting and fruitful platform to customize.

How Chickenfoot differs from Greasemonkey

Chickenfoot operates on the rendered model of a web page.
The goal of Chickenfoot is to enable users to automate and customize web pages without viewing their HTML source. A key step toward this goal is enabling users to identify page elements with words they see in the page rather than the page author's name for the element. For example, the name of the HTML element for the search box on is p, so in Greasemonkey, the code to set the value of the search box would be:
  document.getElementById('p').value = 'my search query';
However, in Chickenfoot, the equivalent line of code would be:
  enter('search the web', 'my search query');
The differences between these two lines of code is significant. The former requires the user to inspect the HTML of the page to discover the name of the element, by either reading the HTML directly or through a more structured representation, such as Firefox's DOM Inspector. The latter simply requires the user to load the page and choose some keywords that appear to identify the box. This makes the code easier to for the author to compose and for others to understand.

Chickenfoot is geared towards end-user programmers as well as hackers.
By offering commands such as click(), enter() and pick(), Chickenfoot provides users with a higher level of abstraction over their actions on a web page, which is more appropriate for an end-user programmer. However, Chickenfoot users are not restricted to this level of abstraction because Chickenfoot can run all valid JavaScript, so all the functions and commands that Greasemonkey users are accustomed to using will still be available in Chickenfoot.

Chickenfoot encourages users to experiment with web pages to develop their scripts.
One of the major contributions of Chickenfoot is the addition of a development environment inside Firefox for web scripting. Since Chickenfoot users are encouraged to work with the rendered model of a web page, being able to look at the page while writing the script is essential. Also, the Output pane makes it convenient to view intermediary results, and the Pattern pane helps users users see what their keyword patterns will match before adding them to their script. Greasemonkey does not provide users with such an environment, so users must switch back and forth between their editor and their browser to create and then test scripts.

Also, not every script that the user creates should be a trigger. For example, suppose you came across a directory listing of files on the web, such as the images directory for the Chickenfoot site. If you wanted to write a quick script to show all of the images in the directory, then you could pop open the Chickenfoot sidebar, and after some experimentation, you might come up with something like this:

for (link = find('link'); link.hasMatch; link = {
  if (link.text.match(/\.(png|gif)$/)) {
    replace(link, '<img src="' + link.text + '">')
There is no reason for this script to be installed as a trigger. If it were, on what URLs would it be triggered to run? That question does not have an easy answer, but Chickenfoot does not force the user to answer it!

Chickenfoot synchronizes commands with page loads
Consider the following snippet of Chickenfoot code to do a search on Google:

  go('') // document.location = ''
  enter('my search terms')
  click('google search')
If the user is not on the Google homepage when he runs this script, then it will not work as intended if enter runs before the Google homepage finishes loading. Chickenfoot is designed so that go will return right away; however, enter will not begin execution if the browser window is in a loading state. This allows the user to execute code after a go that does not depend on page loading without having to wait for the load to finish, so execution is as quick as possible. More importantly, this abstracts the synchronization problem from the user, making it much easier to develop scripts that work with a sequence of pages.


Is Chickenfoot vulnerable to cross-site scripting (XSS) attacks?
Probably. To be honest, we have not yet done an audit of Chickenfoot's security, but given that we allow users to run JavaScript in web pages at a privileged level, it is likely that exploits are possible. Greasemonkey's recent patches for XSS exploits suggest that Chickenfoot has similar vulnerabilities; however, we are hopeful that we can use similar techniques to eliminate these vulnerabilities.

If you have security concerns, then you may want to create a separate Firefox profile for using Chickenfoot and restrict your web surfing on that profile to sites that you trust.


How do I turn off a misbehaved Chickenfoot trigger?
Triggers are Chickenfoot scripts that run automatically when a certain web page is visited. Most of the time, you can easily activate and deactivate triggers just by opening the Chickenfoot sidebar and visiting the Triggers pane, where you'll see a list of the triggers with an activation checkbox for each one. The pane also has an Ignore All Triggers checkbox that lets you disable all of them.

It's possible, however, for a trigger to be so misbehaved that it actually prevents Firefox from working properly, so you can't reach the Chickenfoot sidebar to disable it. If this happens, you can disable all triggers manually by following the directions below.

  1. Start Firefox in safe mode to prevent all extensions (including Chickenfoot) from running.
       firefox -safe-mode
    Firefox will display a dialog offering to reset your toolbars, bookmarks, and preferences. You don't need to reset anything here. Just click Continue in Safe Mode.
  2. Type about:config in the address bar to display Firefox preferences.
  3. Find the chickenfoot.ignoreAllTriggers preference in the list and set it to true.
  4. Close Firefox and restart it normally (not in safe mode). All your triggers will now be deactivated, and you can visit the Triggers pane to disable the offending trigger(s) individually before reactivating all triggers.

©2004-2008 Massachusetts Institute of Technology