• Choose a category
• All
• Classic-Fiction

JavaScript is not unlike the Force (and duct tape): it has a light side and a dark side, and it holds the universe together. Back in the dark days of JavaScript, before the light of Ajax shone upon the land, it mostly got used for doing things like validating form input on the fly (inevitably making it really hard to complete forms amidst the onslaught of alert() boxes) and putting counters on pages. Now that we are firmly ensconced in the land of Web 2.0, JavaScript is the prodigal son, returned to make every web experience animated, dynamic, and completely incompatible with all assistive technologies. All kidding aside, the ability to build richer and more desktop-like user interfaces (UIs) within browsers, combined with some impressive libraries—such as the Yahoo! User Interface Library (YUI), jQuery, Scriptaculous, Prototype, and Dojo—has breathed new life into the web application space and made it a whole lot more fun to work in.

There’s no reason that your Facebook application need be any different.As we saw with FBML in Chapter 6, Facebook has imposed a sandbox on JavaScripts running inside of applications by creating a variant of JavaScript (Facebook JavaScript, or FBJS). It’s not a dramatic variation from the actual language, and primarily exists to protect its users from the potentially massive security and privacy holes you could otherwise open. Allowing third-party developers to run scripts within an existing website is a well-known quandary, and most platform providers solve it by forcing developers to run their JavaScripts within an iFrame which loads content from a different server. Since browsers prevent Cross-Site Scripting (XSS), this effectively prevents the script running inside the iFrame from accessing the Document Object Model (DOM) outside of it. Consider the gaping hole that would be opened, for example, with the following script:

If you followed that recursive bit of naughtiness and knew in advance that Facebook’s main menu bar has the id “navigator”, you would understand that all of the links in the navigation had been deviously rewritten to point to the fictional http://www.securefacebooklogin.com site. Users going to that site could be presented with an entirely authentic-looking Facebook login page, which would capture their usernames and passwords and then redirect them to their destinations without them ever realizing that their accounts had been compromised. That’s obviously a problem, and so if you try to run this code from a Facebook Canvas page, it will fail with an error very similar to “a12345_document.getElementById("navigator") has no properties” (which might give you a clue as to how the Sandbox works).

Here are two main areas that FBJS locks down:

The JavaScript namespace

Any identifiers used in your JavaScript code (function names, variable names, etc.) could collide with names used by Facebook elsewhere on the page, and so your JavaScript will automatically be rewritten to prepend your application ID to all of them (hence the earlier error). For example, the following code block:

function foo(bar) {

var obj = {property: bar};

return obj.property;

}

would automatically become:

function a12345_foo(a12345_bar) {

var a12345_obj = {property: a12345_bar};

return a12345_obj.property;

}

NOTE

I’ll be using 12345 as the Facebook application ID throughout this chapter. If you look at your own app, you’ll find a different ID in its place.

Accessing and modifying the DOM tree

Many of the standard function calls and properties remain, but a number of them behave