Bookmarklet… meh

Getting tired of all the EVO/Android/iPhone love Jake’s been spewing lately? How about something a bit more dry and developery?  As promised in a prior post, here’s a more technical writeup of how I built the WebCenter sharing bookmarklet.  I was hesitant to write about this because it’s not like writing a bookmarklet is new and interesting… there are tons of tutorials on the web after all.  But as with everything, writing about it will make me appreciate the work I put into it more, I suppose.

Building a bookmarklet is pretty simple.  The basic idea is that a user clicks on the bookmark to execute some javascript to do what you want.  Creating a sharing bookmarklet can be a bit of a challenge depending on the implementation path you take. You can take a look at the various approaches by testing out a service called Shareaholic, a service that aggregates a bunch of sharing tools together as a Chrome extension or Firefox addon.  The simplest strategy for a sharing bookmarklet is to launch a new window/tab like Facebook or Digg, but personally, I’m not a fan of launching new windows so I decided to take a different approach.  Other sharing bookmarklets are “inserted” inside of the page you’re currently browsing.  Google Reader‘s and Posterous‘ bookmarklets are good examples of this. There are a few simple tricks necessary in order to build a bookmarklet like this.  Let’s use the following diagram for reference:

There are a few pieces to that make this bookmarklet possible:

• Javascript to execute on the foreign page (bookmarklet.js) — this is injected by the bookmarklet itself through a script tag insertion.
• Content iframe originating from the domain you’re sharing to (bookmarklet.html, #3 in the diagram above) — this is necessary because our bookmarklet needs to interact with a REST API on the domain where the user will be sharing to (in this case, the host/domain where WebCenter).
• Proxy iframe (#4 in the diagram above) — this iframe is hidden off of the screen and is used simply to trigger events that happen on the parent.  I’ll go into more detail as to why this is needed later.

Here’s the flow:

1. User triggers the bookmarklet (an inline javascript in an anchor link that a user adds to their bookmarks bar).  Upon execution, a new script tag is inserted into the foreign page and does the following:
   1. Inserts a stylesheet to the page defining the style of the dialog box we’re going to create (#2).
   2. Defines a div container for us to insert our DOM elements into which makes it easier for cleanup when after the bookmarklet is used.
   3. Inserts the content iframe (#3) which points to bookmarklet.html on the WebCenter host.
   4. Inserts the proxy iframe (#4) which points to proxy_frame.html on the WebCenter host.
2. At this point, the sharing dialog window has been initialized and the iframes have been rendered.  Our bookmarklet communicates with the WebCenter REST API directly (#3).  Before presenting the user with the “publisher” (sharing textarea), we need to determine if the user can access the REST API.  Since our bookmarklet app is hosted on the same domain as the WebCenter app, we don’t can trigger the SSO system to authenticate the user if it’s needed (no fancy OAuth needed — good thing because WebCenter doesn’t support OAuth yet).  Upon a successful SSO authentication, the iframe in #3 is reloaded and the REST API is called in order to paint the rest of the form.
3. The only interaction left is when the user clicks the “Share” button.  The Share button is purposefully inserted on the host page (not the iframe in #3).  The reason for this is the share button will need to be able to trigger the dialog to close and also clean up all of the HTML that was inserted onto the page.  You can’t do that if the button is inside the #3 iframe.  However, this causes us another issue.  How do we trigger the form submission in iFrame #3?  Because of cross domain rules, you can’t trigger an event in another frame that’s from a separate domain.  Enter iFrame #4, the proxy_frame.html.  Before I explain how this works, go read Michael Mahemoff‘s excellent article about Cross-Domain Communication with iFrames — the technique I use is the “Window Size Monitoring” hack.  The hack works like this…
   1. The main page (i.e., main parent) creates two iframes (#3 and #4), both of which reside on the same domain, but not necessarily the same domain as its parent.
   2. The first iframe contains the actual iframe you want the user to interact with (#3).  The second iframe is the “proxy” iframe (#4).  The proxy iframe’s purpose is to respond to events that the main parent triggers.
   3. When these trigger is executed, the proxy iframe will execute some javascript in it’s sibling iframe (#3).  But how does the main parent trigger an event on the proxy iframe which resides on a different domain, you ask?  iframes are like little windows within a larger window.  They can be resized.  One of the events a window can respond to is a “resize” event.  So, the trick is to hide this proxy iframe out of view from the user (position:absolute;top:-9999px;width:0;height:0). In the proxy_frame.html page, add an event listener on the window that listens for “resize” events:

So, that’s the gist of it.  Questions… ask below.