0xDECAFBAD » mozilla

HTML5 drag and drop in Firefox 3.5

l.m.orchard — Thu, 16 Jul 2009 02:26:40 +0000

Oh hey, look! It’s another blog post—and this one is cross-posted on hacks.mozilla.com. I won’t say this is the start of a renewed blogging habit, but let’s see what happens.

Drag and drop is one of the most fundamental interactions afforded by graphical user interfaces. In one gesture, it allows users to pair the selection of an object with the execution of an action, often including a second object in the operation. It’s a simple yet powerful UI concept used to support copying, list reordering, deletion (ala the Trash / Recycle Bin), and even the creation of link relationships.

Since it’s so fundamental, offering drag and drop in web applications has been a no-brainer ever since browsers first offered mouse events in DHTML. But, although mousedown, mousemove, and mouseup made it possible, the implementation has been limited to the bounds of the browser window. Additionally, since these events refer only to the object being dragged, there’s a challenge to find the subject of the drop when the interaction is completed.

Of course, that doesn’t prevent most modern JavaScript frameworks from abstracting away most of the problems and throwing in some flourishes while they’re at it. But, wouldn’t it be nice if browsers offered first-class support for drag and drop, and maybe even extended it beyond the window sandbox?

As it turns out, this very wish is answered by the HTML 5 specification section on new drag-and-drop events, and Firefox 3.5 includes an implementation of those events.

If you want to jump straight to the code, I’ve put together some simple demos of the new events.

I’ve even scratched an itch of my own and built the beginnings of an outline editor, where every draggable element is also a drop target—of which there could be dozens to hundreds in a complex document, something that gave me some minor hair-tearing moments in the past while trying to make do with plain old mouse events.

And, all the above can be downloaded or cloned from a GitHub repository I’ve created especially for this article—which continues after the jump.

The New Drag and Drop Events

So, with no further ado, here are the new drag and drop events, in roughly the order you might expect to see them fired:

dragstart: A drag has been initiated, with the dragged element as the event target.
drag: The mouse has moved, with the dragged element as the event target.
dragenter: The dragged element has been moved into a drop listener, with the drop listener element as the event target.
dragover: The dragged element has been moved over a drop listener, with the drop listener element as the event target. Since the default behavior is to cancel drops, returning false or calling preventDefault() in the event handler indicates that a drop is allowed here.
dragleave: The dragged element has been moved out of a drop listener, with the drop listener element as the event target.
drop: The dragged element has been successfully dropped on a drop listener, with the drop listener element as the event target.
dragend: A drag has been ended, successfully or not, with the dragged element as the event target.

Like the mouse events of yore, listeners can be attached to elements using addEventListener() directly or by way of your favorite JS library.

Consider the following example using jQuery, also available as a live demo:


    Drag me!
    Drop here!

 
<script type="text/javascript">
    $(document).ready(function() {
        $('#newschool .dragme')
            .attr('draggable', 'true')
            .bind('dragstart', function(ev) {
                var dt = ev.originalEvent.dataTransfer;
                dt.setData("Text", "Dropped in zone!");
                return true;
            })
            .bind('dragend', function(ev) {
                return false;
            });
        $('#newschool .drophere')
            .bind('dragenter', function(ev) {
                $(ev.target).addClass('dragover');
                return false;
            })
            .bind('dragleave', function(ev) {
                $(ev.target).removeClass('dragover');
                return false;
            })
            .bind('dragover', function(ev) {
                return false;
            })
            .bind('drop', function(ev) {
                var dt = ev.originalEvent.dataTransfer;
                alert(dt.getData('Text'));
                return false;
            });
    });
script>

Thanks to the new events and jQuery, this example is both short and simple—but it packs in a lot of functionality, as the rest of this article will explain.

Before moving on, there are at least three things about the above code that are worth mentioning:

Drop targets are enabled by virtue of having listeners for drop events. But, per the HTML 5 spec, draggable elements need an attribute of draggable="true", set either in markup or in JavaScript.

Thus, $('#newschool .dragme').attr('draggable', 'true').
The original DOM event (as opposed to jQuery’s event wrapper) offers a property called dataTransfer. Beyond just manipulating elements, the new drag and drop events accomodate the transmission of user-definable data during the course of the interaction.
Since these are first-class events, you can apply the technique of Event Delegation.
What’s that? Well, imagine you have a list of 1000 list items—as part of a deeply-nested outline document, for instance. Rather than needing to attach listeners or otherwise fiddle with all 1000 items, simply attach a listener to the parent node (eg. the
element) and all events from the children will propagate up to the single parent listener. As a bonus, all new child elements added after page load will enjoy the same benefits.
Check out this demo, and the associated JS code to see more about these events and Event Delegation.

Using dataTransfer

As mentioned in the last section, the new drag and drop events let you send data along with a dragged element. But, it’s even better than that: Your drop targets can receive data transferred by content objects dragged into the window from other browser windows, and even other applications.

Since the example is a bit longer, check out the live demo and associated code to get an idea of what’s possible with dataTransfer.

In a nutshell, the stars of this show are the setData() and getData() methods of the dataTransfer property exposed by the Event object.

The setData() method is typically called in the dragstart listener, loading dataTransfer up with one or more strings of content with associated recommended content types.

For illustration, here’s a quick snippet from the example code:

var dt = ev.originalEvent.dataTransfer;    
dt.setData('text/plain', $('#logo').parent().text());
dt.setData('text/html', $('#logo').parent().html());
dt.setData('text/uri-list', $('#logo')[0].src);

On the other end, getData() allows you to query for content by type (eg. text/html followed by text/plain). This, in turn, allows you to decide on acceptable content types at the time of the drop event or even during dragover to offer feedback for unacceptable types during the drag.

Here’s another example from the receiving end of the example code:

var dt = ev.originalEvent.dataTransfer;    
$('.content_url .content').text(dt.getData('text/uri-list'));
$('.content_text .content').text(dt.getData('text/plain'));
$('.content_html .content').html(dt.getData('text/html'));

Where dataTransfer really shines, though, is that it allows your drop targets to receive content from sources outside your defined draggable elements and even from outside the browser altogether. Firefox accepts such drags, and attempts to populate dataTransfer with appropriate content types extracted from the external object.

Thus, you could select some text in a word processor window and drop it into one of your elements, and at least expect to find it available as text/plain content.

You can also select content in another browser window, and expect to see text/html appear in your events. Check out the outline editing demo and see what happens when you try dragging various elements (eg. images, tables, and lists) and highlighted content from other windows onto the items there.

Using Drag Feedback Images

An important aspect of the drag and drop interaction is a representation of the thing being dragged. By default in Firefox, this is a “ghost” image of the dragged element itself. But, the dataTransfer property of the original Event object exposes the method setDragImage() for use in customizing this representation.

There’s a live demo of this feature, as well as associated JS code available. The gist, however, is sketched out in these code snippets:

var dt = ev.originalEvent.dataTransfer;    
 
dt.setDragImage( $('#feedback_image h2')[0], 0, 0);
 
dt.setDragImage( $('#logo')[0], 32, 32); 
 
var canvas = document.createElement("canvas");
canvas.width = canvas.height = 50;
 
var ctx = canvas.getContext("2d");
ctx.lineWidth = 8;
ctx.moveTo(25,0);
ctx.lineTo(50, 50);
ctx.lineTo(0, 50);
ctx.lineTo(25, 0);
ctx.stroke();
 
dt.setDragImage(canvas, 25, 25);

You can supply a DOM node as the first parameter to setDragImage(), which includes everything from text to images to canvas elements. The second two parameters indicate at what left and top offset the mouse should appear in the image while dragging.

For example, since the #logo image is 64×64, the parameters in the second setDragImage() method places the mouse right in the center of the image. On the other hand, the first call positions the feedback image such that the mouse rests in the upper left corner.

Using Drop Effects

As mentioned at the start of this article, the drag and drop interaction has been used to support actions such as copying, moving, and linking. Accordingly, the HTML 5 specification accomodates these operations in the form of the effectAllowed and dropEffect properties exposed by the Event object.

For a quick fix, check out the a live demo of this feature, as well as the associated JS code.

The basic idea is that the dragstart event listener can set a value for effectAllowed like so:

var dt = ev.originalEvent.dataTransfer;
switch (ev.target.id) {
    case 'effectdrag0': dt.effectAllowed = 'copy'; break;
    case 'effectdrag1': dt.effectAllowed = 'move'; break;
    case 'effectdrag2': dt.effectAllowed = 'link'; break;
    case 'effectdrag3': dt.effectAllowed = 'all'; break;
    case 'effectdrag4': dt.effectAllowed = 'none'; break;
}

The choices available for this property include the following:

none: no operation is permitted
copy: copy only
move: move only
link: link only
copyMove: copy or move only
copyLink: copy or link only
linkMove: link or move only
all: copy, move, or link

On the other end, the dragover event listener can set the value of the dropEffect property to indicate the expected effect invoked on a successful drop. If the value does not match up with effectAllowed, the drop will be considered cancelled on completion.

In the a live demo, you should be able to see that only elements with matching effects can be dropped into the appropriate drop zones. This is accomplished with code like the following:

var dt = ev.originalEvent.dataTransfer;
switch (ev.target.id) {
    case 'effectdrop0': dt.dropEffect = 'copy'; break;
    case 'effectdrop1': dt.dropEffect = 'move'; break;
    case 'effectdrop2': dt.dropEffect = 'link'; break;
    case 'effectdrop3': dt.dropEffect = 'all'; break;
    case 'effectdrop4': dt.dropEffect = 'none'; break;
}

Although the OS itself can provide some feedback, you can also use these properties to update your own visible feedback, both on the dragged element and on the drop zone itself.

Conclusion

The new first-class drag and drop events in HTML5 and Firefox make supporting this form of UI interaction simple, concise, and powerful in the browser. But beyond the new simplicity of these events, the ability to transfer content between applications opens brand new avenues for web-based applications and collaboration with desktop software in general.

7 facts about me

l.m.orchard — Fri, 23 Jan 2009 16:59:54 +0000

So, it finally happened—I’ve been tagged by Stephen Donner. I’ve not been one to follow memes in this blog, but this one’s been going around the Mozillasphere for awhile now and has been kind of interesting. I’m half-tempted to bookmark and tag all the entries I’ve caught so far. Anyway, the rules:

Link to your original tagger(s) and list these rules in your post.
Share seven facts about yourself in the post.
~~Tag seven people at the end of your post by leaving their names and the links to their blogs.~~
~~Let them know they’ve been tagged.~~

Now, for your random facts, after the jump:

My wife is a nerd, who tracked me down via a user name shown in the webcam picture I used for my Yahoo! Personals ad, in order to avoid paying to reply. Dial-up BBSes and DOOR games played a part in our courtship.
We have two ocicats, littermates named Puck and Inanna. They’re both very cute and are more awesome than anyone else’s cats.
I have sleep apnea, and use a CPAP machine every night. If you snore, go get tested. Heart disease, of which my snoring father died, is one of many possible consequences of untreated sleep apnea.
Although I have been a computer nerd since the age of 7, I had the wild notion in starting college that I wanted to be a journalist or a psychologist. Luckily, the web took off during my freshman year, which let me be a little of all the above. I’m not sure why I ever thought I’d be anything other than a computer nerd.
I’m a complete introvert and though I work hard at being sociable, I need a day or two alone for every half-day or so spent being social. My main coping mechanism since even before my teenage years was to make friends from behind a keyboard and screen, and the internet has made that even more scalable as I’ve grown up. And now, I get to work that way too—HUGE SUCCESS!
In my senior year of High School, I won 2nd place in the Ayn Rand Institute’s The Fountainhead essay contest. This was the culmination of having read every scrap of Ayn Rand’s writing I could get my hands on throughout High School. I used the money to take a summer trip to visit a friend who’d moved to Texas and to buy my well used, now dead palmtop PC.
I like extremely hot spicy food, insanely hop-saturated beer, Irish whiskey, and fresh locally roasted coffee.

Per Ben Hearsum, I think I’ll make this a leaf node in the meme spanning the Mozillasphere. In a quick 5 minute search, it looks like most blogging Mozillans have already been tagged, and I’m not going to spread the contagion outside the organization. :)

Enter the LizardFeeder

l.m.orchard — Tue, 06 Jan 2009 00:01:54 +0000

The Mozilla Tree

Behind Firefox is Mozilla, and behind Mozilla is a community. And the Mozilla community acts a lot like an ecosystem, which can be visualized as a kind of living tree—not to confused with the mozilla-central tree. Oh yeah, and Mozilla is the name of both a Foundation and a Corporation.

Confused yet? If not, then we should talk so you can explain it to me, because it all looks pretty tangly and intertwingled to me. Nonetheless, it seems to work, and produces a good chunk of my favorite software and technologies.

There are many efforts to track what’s going on—including planets and newsletters and bugzillas and wikis and repositories and tinderboxen. Some of these resources report on, or are driven by, the activity occurring in the others. Some are automated, and others are carefully stitched together by hand. None offer a full picture of what’s going on in the Mozilla galaxy in a way that’s casually comprehensible by a sane human being.

Of course, that’s not a slight against any of these sites or the people maintaining them—extracting an overview from such an organic phenomenon is neither easy nor straightforward. But, it might be fun to try.

As an infovore and avid practitioner of continuous partial attention, my first impulse is to reach for a firehose and stick my head into the stream. Relax, defocus, and try to let my pattern recognizers do their thing—sometimes those pattern recognizers are in my head, and sometimes they’re written in Python.

Firefox Victory!

But, for Mozilla, I couldn’t find a stream of sufficient volume or completeness to satisfy me or my robots. Happily, though, my feeding urge found itself aligned with a project to discover the patterns of contribution in the Mozilla community and to find a way to thank the contributors responsible.

So, while we’re still working on the thank-you angle, allow me to introduce you to the Lizardfeeder. The LizardFeeder is a feed aggregator, whose source code is built atop Sam Ruby’s Planet Venus. The LizardFeeder pulls together and archives activity streams from a wide variety of Mozilla community sources. Beyond the usual human-readable pages produced by a blog-gathering Planet, the LizardFeeder accumulates statistical and historical data meant for consumption and analysis by robots.

At present, the only robot navigating the LizardFeeder archives is an AJAX-ified user interface that animates the firehose as a near real-time or time-lapsed stream of events scrolling by.

This is just meant as a conversation starter, though. I’m hoping to gather feedback and find more sources, as well as to entice creative community members to come up with more sophisticated visualizations of this data.

So, take a look, check it out, and let me know what you think!

Improving my Delicious command for Ubiquity

l.m.orchard — Sun, 07 Sep 2008 06:20:20 +0000

After writing up my first stab at a Delicious command for Ubiquity, I planned to continue revising it based on feedback and to work on exploring more of what Ubiquity enables. I started looking into writing my own nouns for tag suggestions, as well as playing with page load and browser startup hooks. And, I also started poking at a little bit of deeper extension development, which took up most of my time today.

I’ve updated my UbiquityCommands page and checked in my latest revision of the Delicious command.

The main new feature is a status bar item reporting bookmarks for the current page:

As you can see above, the command now comes with a status bar panel powered by the Delicious URL info JSON feed, providing bookmarking info on every page visited. It shows a bookmark count, a tooltip with further information, and sends the user to the URL info page on Delicious when clicked. It mostly works, but it could use some looking at. This is my first time really cracking open the hood on Firefox and XUL, and so I’m feeling around in the dark.

Specifically, I’m using Ubiquity’s page load hook—but I’m also trying to augment that by tracking tab selection events, in order to keep the status bar info updated for the active tab. But then, that leads me to trying to track new windows, to attach the tab selection event handler for every newly opened window. Or I could just be barking up the wrong tree entirely. At any rate, the code is probably brain-dead dumb, so I hope someone can clue me into a better way.

Writing a Delicious command for Ubiquity

l.m.orchard — Mon, 01 Sep 2008 05:37:03 +0000

In my last post, I got all fluffy about how cool Ubiquity is but didn’t share any code to prove the point. As it happens, I have come up with at least one useful command that I’m starting to use habitually in posting bookmarks to Delicious. You can subscribe to my command or check out the full source—this post will serve as a dissection of the thing. Since this will be fairly lengthy, follow along after the jump.

Oh, and it’s been awhile since I posted something this in-depth around here, so feel free to let me know how this first draft works. And, bug reports and patches are of course welcome.

To begin, consider the following code starting off the command source code:

/**
 * share-on-delicious - an Ubiquity command for sharing bookmarks on
 * delicious.com
 *
 * l.m.orchard@pobox.com
 * http://decafbad.com/
 * Share and Enjoy!
 */
var uext = Application.extensions.get('ubiquity@labs.mozilla.com');
 
var cookie_mgr = Components.classes["@mozilla.org/cookiemanager;1"]
    .getService(Components.interfaces.nsICookieManager);

The first thing to note here is that a short header comment introduces the command. This isn’t required, but it’s a good idea. It’s also something you can’t really do with bookmarklets. On the other hand, Greasemonkey user scripts expect metadata about the script to be provided here, but Ubiquity doesn’t use this convention.

Second, notice that the code accesses some chrome-level resources. Again, this is something unavailable to bookmarklets and Greasemonkey user scripts. Just take a look at the FUEL library documentation to get a quick sense of what’s available using that simplified API, not to mention what’s available using the lower-level browser APIs.

Now, check out this next chunk of code, which begins the construction of an Ubiquity command:

CmdUtils.CreateCommand({
 
    name:        
        'share-on-delicious',
    icon:
        'http://delicious.com/favicon.ico',
    description: 
        'Share the current page as a bookmark on delicious.com',
    help:        
        'Select text on the page to use as notes, or enter your own ' + 
        'text after the command word.  You can also assign tags to the '+ 
        'bookmark with the "tagged" modifier, and alter the bookmark ' + 
        'default page title with the "entitled" modifier.  Note that ' + 
        'you must also already be logged in at delicious.com to use ' +
        'this command.',
 
    homepage:   
        'http://decafbad.com',
    author: { 
        name: 'Leslie Michael Orchard', 
        email: 'l.m.orchard@pobox.com' 
    },
    license:
        'MPL/GPL/LGPL',

Whereas Greasemonkey scripts support metadata in the header comment, the Ubiquity command script API works a little differently.

The CmdUtils module provided by Ubiquity offers a CreateCommand function, which expects an object as a parameter. The object literal whose construction is begun in the code above serves as a self-contained package for the command, bearing metadata describing the command as well as containing all the code necessary to implement it.

So, in the above code block, you can see the machine-readable description of the command—including a command name, display icon, home page URL, author information, and license. The command name (share-on-delicious) will be used by the Ubiquity command parser, but the rest of the description will also be used in the list of commands available to the user, invoked by the command-list command, like so:

Moving along, this next chunk of code introduces the first functional bits of the command:

    takes: { notes: noun_arb_text },
    modifiers: { 
        tagged:  noun_arb_text,
        entitled: noun_arb_text
    },

Like smart keyword shortcut bookmarks, Ubiquity commands accept user-supplied input. But, what’s unique to Ubiquity is that it employs a parser whose goal is to support something approximating natural language. At present, this results in commands that support a single primary argument—declared above with the takes property—and any number of additional keyword modifiers—declared above by the modifiers property.

For the command under construction here, this establishes a pattern something like the following:

share-on-delicious {notes} [tagged {tags} entitled {title}]

Content for the {notes} argument can either be typed directly by hand, or it can be supplied by text highlighted on the page. To use highlighted text, you can either issue the command alone, or use the word this for the {notes} argument before including further modifiers.

The modifiers tagged and entitled are optional, and can be used in any order. Each of these keywords signifies the start of a different argument—which unfortunately can collide with the literal data supplied for notes, which will hopefully be a rare occurrence.

All of this adds up command invocations including the following:

share-on-delicious
share-on-delicious I really like this page tagged nifty amusing
share-on-delicious this entitled This bookmark has no tags
sh this tagged osx software apple entitled This is good OS X software

That last example is important—since I have no other commands starting with “sh“, I can abbreviate the full command. Ubiquity only requires enough of a command name to disambiguate it within your collection of commands.

Another thing to note is the use of the constant value noun_arb_text, which declares that these arguments should expect any arbitrary text as input.

This facility is not exploited for the present command, but Ubiquity defines noun types. These include concepts such as plain text, dates, address book contacts, browser tabs, bookmark tags, and more. You can define your own noun types, as well as implement suggestion schemes that help guide the user toward constructing useful input values in the command interface. You can read more about this in the official author tutorial.

Next up is a quick bit of command-specific configuration:

    /**
     * Command configuration settings.
     */
    _config: {
        // Base URL for the delicious v1 API
        api_base:      'https://api.del.icio.us',
 
        // Domain and name of the delicious login session cookie.
        cookie_domain: '.delicious.com',
        cookie_name:   '_user'
    },

Since this command will be posting to Delicious via the V1 API, it’s handy to declare the base URL for the API in an easily changed spot. That way, you could change this value later on to point the command at another implementation of the API.

Additionally, this command will employ a little-known authentication trick supported by the Delicious API that accepts the user’s login cookie set by the Delicious website—this “cookie god” auth is used by the official Delicious addon for Firefox. It’s handy for piggybacking on the website login and removing the need to ask the user for their username and password again and possibly storing it in an insecure manner.

In fact, this next chunk of code defines a utility method to rummage through the cookie jar:

    /**
     * Dig up the Delicious login session cookie.
     */
    _getUserCookie: function() {
        var iter = cookie_mgr.enumerator;
        while (iter.hasMoreElements()) {
            var cookie = iter.getNext();
            if( cookie instanceof Components.interfaces.nsICookie && 
                cookie.host.indexOf(this._config.cookie_domain) != -1 && 
                cookie.name == this._config.cookie_name) {
                return decodeURIComponent(cookie.value);
            }
        }
    },

The method defined above, ._getUserCookie(), uses the browser’s cookie manager and the values defined in the previous configuration section to find the login session cookie set for Delicious. Take note that this is far beyond the allowed capabilities of bookmarklets and Greasemoney user scripts—this is digging straight into the browser itself, skipping past the usual content-space security restrictions.

In other words: In Ubiquity, the gun is loaded and you should be careful.

Moving along, consider this next utility method:

    /**
     * Given input data and modifiers, attempt to assemble data necessary to
     * post a bookmark.
     */
    _extractBookmarkData: function(input_obj, mods) {
        return {
            _user:
                this._getUserCookie(),
            url:
                context.focusedWindow.location,
            description:
                mods.entitled.text || context.focusedWindow.document.title,
            extended: 
                input_obj.text,
            tags:
                mods.tagged.text
        };
    },

Named ._extractBookmarkData(), this utility method accepts the results of Ubiquity’s parser interpreting the primary argument and modifier arguments supplied by the user. Using these data structures, it attempts to build a structure representing the fields of a Delicious bookmark.

The _user field is used for authentication via the site login cookie. The url is set from the location bar of the current page. The description, or title, field of the bookmark is taken from either the entitled modifier or the title of the current page. The tags, if any, come from the tagged modifier. And, finally, the extended notes for the bookmark are taken from the primary input argument of the command.

As you’ll see shortly, this utility method will be used in both the preview and the execution of the command.

Next, there’s one more utility method to cover:

    /**
     * Given an object, build a URL query string
     */
    _buildQueryString: function(data) {
        var qs = [];
        for (k in data) if (data[k]) 
            qs.push( encodeURIComponent(k) + '=' + 
                encodeURIComponent(data[k]) );
        return qs.join('&');
    },

In anticipation of using the Delicious V1 API, the ._buildQueryString() method accepts an object and constructs a URL query string from the encoded properties of the object. This will be paired with the ._extractBookmarkData() method to supply data for API calls.

Moving along, it’s time to start digging into the meat of this Ubiquity command:

    /**
     * Present a preview of the bookmark under construction during the course
     * of composing the command.
     */
    preview: function(pblock, input_obj, mods) {
 
        var bm          = this._extractBookmarkData(input_obj, mods);
        var user_cookie = this._getUserCookie();
        var user_name   = (user_cookie) ? user_cookie.split(' ')[0] : '';
 
        var ns = { user_name: user_name, bm: bm };
        var tmpl;

With this code, the implementation of command method .preview() has begun. This method is used by Ubiquity to generate a live preview of the command. Called with a DOM node (pblock) and partially completed command input (input_obj and mods), this method is expected to build a representation of the command’s results in the DOM node. As the user types, this method will be called over and over again, ideally offering feedback as the user composes a command.

Continuing on, consider this next chunk of code checking the validity of command input:

        if (!user_name) {
 
            // If there's no user name, there's no login, so this command won't work. 
            tmpl = [ 
                'No active user found - log in at ', 
                ' ',
                'delicious.com ', 
                'to use this command.
'
            ].join('');
 
        } else if (!bm.description) {
 
            // If there's no title, then this is an error too.
            tmpl = [ 
                'A title is required for bookmarks on ', 
                ' ',
                'delicious.com ', 
                '
'
            ].join('');

This chunk of code first checks for a user name, which can be extracted from a valid Delicious login cookie, if one was found. If not found, the command will fail—so the preview built here will instruct the user to login at Delicious before going further.

The second precondition for using the command is that the bookmark has been given a title. By default, this is the title of the current page—but, some pages don’t offer titles. So, an error needs to be flagged if the user hasn’t manually supplied a title in this case.

Finally, notice in both of these error cases, a string of HTML is composed in the variable tmpl. This will be used at the end of the method to populate the DOM node passed in as pblock.

Now, assuming that all the command’s prerequisites have been met, it’s time to try constructing a proper preview for the results of this command:

        } else {
 
            // Attempt to construct a vaguely delicious-esque preview of a bookmark.
            tmpl = [ 
                '',
                '',
                    'Share a bookmark at  ',
                        'delicious.com/${user_name}:
',
                    '',
                        '',
                        '${bm.description}',
                        '${bm.url}',
                        bm.extended ? 
                            '${bm.extended}
' : '',
                        bm.tags ?
                            'tags: ${bm.tags}
' : '',
                    '
',
                '
'
            ].join("\n");
 
        }
 
        pblock.innerHTML = CmdUtils.renderTemplate(tmpl, ns);
    },

Building on the notion that previews are built in a DOM node, the code above uses both CSS and HTML to assemble a quick-and-dirty facsimile of a Delicious bookmark—which will be rendered like this:

Also note that Ubiquity provides a template engine for use in generating content—namely the JavaScript Templates engine from the TrimPath project. This engine may eventually be replaced with another, but the notion is that Ubiquity will provide tools to more easily generate previews and more.

The conclusion of the .preview() method uses the template engine with a call to CmdUtils.renderTemplate() to inject content into the preview element by way of the .innerHTML property.

Now that the preview is out of the way, it’s time to get down to implementing the execution of the command:

    /**
     * Attempt to use the delicious v1 API to post a bookmark using the 
     * command input
     */
    execute: function(input_obj, mods) {
        var bm          = this._extractBookmarkData(input_obj, mods);
        var user_cookie = this._getUserCookie();
        var user_name   = (user_cookie) ? user_cookie.split(' ')[0] : '';
 
        if (!user_name) {
            // If there's no user name, there's no login, so this command won't work. 
            displayMessage('No active user found - log in at delicious.com ' +
                'to use this command.');
            return false;
        }
 
        if (!bm.description) {
            // If there's no title, somehow, then this is an error too.
            displayMessage("A title is required for bookmarks at delicious.com");
            return false;
        }

Mirroring the .preview() method, the .execute() method first checks for validity of the arguments given by the user. A missing user name or title result in a notification that the command has failed.

But, if the arguments are all valid, it’s time to actually issue a request to the Delicious V1 API:

        var path = '/v1/posts/add';
        var url  = this._config.api_base + path;
 
        var req = Components.classes["@mozilla.org/xmlextras/xmlhttprequest;1"].
            createInstance();
 
        req.open('POST', url, true);
 
        req.onload = function(ev) { 
            displayMessage('Bookmark "' + bm.description + '" ' + 
                'shared at delicious.com/' + user_name);
        }
 
        req.onerror = function(ev) { 
            displayMessage('ERROR: Bookmark "' + bm.description + '" ' + 
                ' NOT shared on delicious.com/' + user_name);
        }

Using the base URL for the Delicious API declared earlier in the configuration section, the .execute() method constructs an API URL for the /v1/posts/add method. Then, it creates an instance of XMLHttpRequest from the browser to be used in sending the API request. Event handlers are registered with the object to present notifications to the user indicating whether or not the API request was successful.

At long last, it’s time to wrap up this method and make the API request:

        req.setRequestHeader('Authorization', 'Basic Y29va2llOmNvb2tpZQ=='); // btoa('cookie:cookie')
 
        var mediator = Components.classes["@mozilla.org/appshell/window-mediator;1"].
            getService(Components.interfaces.nsIWindowMediator);
        var win = mediator.getMostRecentWindow(null);
        var user_agent = win.navigator.userAgent + ";Ubiquity-share-on-delicious";
 
        req.setRequestHeader("User-Agent", user_agent);      
 
        req.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
        req.send(this._buildQueryString(bm));
    },
 
    EOF:null // I hate trailing commas
});

The login cookie authentication supported by the Delicious V1 API is triggered by supplying a user name / password pair of cookie, which is done by setting the Authorization request header. The login cookie is then expected to be passed in as the POST variable _user, which is done in the ._extractBookmarkData() utility method.

Another bit here that shows more access of browser resources is the construction of a unique User-Agent header for this API call based on the browser’s own User-Agent string, something that’s suggested in the guidelines for using the Delicious API.

Finally, the .execute() method—and the command itself—is wrapped up with by sending off the bookmark data encoded as POST form variables with the ._buildQueryString() utility method.

And, that’s it—a command-driven Delicious browser extension in a little over 200 lines of code. There’s still more to be done to really make this thing full-featured, but I think this shows off the basic features of Ubiquity. I’m hoping to dig in deeper and explore further, taking a look at running Greasemonkey-style code at browser startup and page load, as well as playing with some more browser chrome features.

Ubiquity cracks open personal mashup tinkering

l.m.orchard — Sun, 31 Aug 2008 05:07:22 +0000

When I was a wee hacker, I lived my digital life though a Commodore 64. I played games on it, did homework, talked to people far away—you know, all the stuff they showed in the pictures on the box. I also took things apart—both the machine itself and software running on it. I grew up learning that my digital environment was ultimately understandable, susceptible to tinkering, and open to being bent to my own purposes.

From the Commodore 64, I graduated eventually to terminals and text editors, opening portals mostly onto computers elsewhere via powerful UNIX command shells. And, of course, over the past decade, this has largely given way to life in a browser.

Yet, for a little while, particularly in the first few years of browsers, freedom to tinker seemed cramped. JavaScript had yet to arrive, and was a little messy when it did. There was no relatively easy addon development. And, though the portals opened by a browser were richer than those provided by terminals, the paths of navigation defined by links controlled by site owners offered less freedom of movement than UNIX commands. I could create my own pages, but I couldn’t do much to others’ pages.

But then, javascript: URLs came around, dots were connected, and bookmarklets were born. Suddenly, it was possible to customize my browsing environment with arbitrary JavaScript code having access to the current page—no matter whose page it was. And, through the various tricks of the AJAX trade, bookmarklets have only gotten more capable throughout the years.

Smart keyword shortcuts came around a little later, allowing quick access to bookmarks via simple keywords typed into the location bar. The smart part, though, came in the form of bookmarked URLs with placeholders and keywords given arguments to fill the placeholders—allowing not only quick access to bookmarked pages but also search engine forms bookmarked with late-bound fields.

Bookmarklets inherited the benefits of smart keyword shortcuts. The same placeholder in http: URLs can be inserted into the code of a javascript: URL, thus parameterizing the JavaScript code and incidentally turning the location bar into a kind of primitive command line. For example, one of my most heavily used “addresslets” is based on John Resig’s original “Super-Fast Delicious Bookmarklet”.

Another leap in prying open the browser tinkering space came in the form of Greasemonkey—an addon-powered environment created explicitly for the purpose of end-user scripting applied to others’ pages. Greasemonkey user scripts can do more than bookmarklets, and with a much better development environment to boot. And, though a user script can’t do quite as much as a proper browser addon, they’re much easier to hack on and distribute.

Now, consider one of Mozilla Labs‘ newest projects, named Ubiquity. This rough and experimental addon for Firefox combines and improves upon everything I’ve described so far:

Ubiquity is a hackable command line environment, better than bookmarklets and smart keyword shortcuts;
Ubiquity enables persistent customization of others’ pages, not unlike Greasemonkey;
Ubiquity facilitates live in-browser creation and web-based subscription to user commands and scripts;
Ubiquity gives access to browser chrome resources without a need for frequent restarts;

So far, most of the commands I see popping up since the 0.1 release have not accomplished much more than smart keyword shortcuts in the location bar could. But, it’s early yet, and Ubiquity is far from limited to these commands.

Once the basics have been well-explored, I expect to see more people taking a crack at the broader capabilities offered by Ubiquity. Bookmarklets and Greasemonkey can’t access browser chrome—but Ubiquity can. Ubiquity also offers a user interface that’s so much more promising than keyword shortcuts, including command previews and typed parameters with suggestions.

Ubiquity promises web-wide mashups directed by a conversational command interface. All in all, the potential of this makes me feel like my digital environment—browser and web as a whole—is getting even more intimately, personally hackable.

It’ll be very interesting to see where this project goes.

Moz08: Rockslides and Blackouts and Bears – Oh My!

l.m.orchard — Mon, 04 Aug 2008 21:15:23 +0000

Since the beginning, I’ve been a Mozilla fanboy. But, up until very recently, I’ve only shown that as a user and a verbal supporter, with a shallow understanding or participation in what’s really done in the Mozilla community. Sure, I’ve checked out source code from time to time going back to the first code release, built and poked at it, but I’ve never really contributed back.

But now, I’m an employee of the Mozilla Corporation, and I feel like I found a little-known cheat code for getting into the place where all the cool stuff happens. See, I just got back from this thing called the Mozilla 2008 Firefox Plus Summit—and if I was overwhelmed by the initial Mozilla Firehose after coming on-board, I’m entirely gobsmacked now.

The event—having taken place in the bear-infested, rockslide-prone, electricity-deficient wilds of Whistler, BC in Canada—was attended by not only employees of the corporation itself, but a selection of invitees from around the Mozilla community. Throughout the course of the event, I felt humbled by the efforts of everyone and have come away with a feeling that I really need to step up my game. Somehow, it seems I managed to sneak into the place without having first run the decade-old traditional gauntlet of meritocracy and contribution.

Being a newbie of just a few months, I barely know anyone at Mozilla, so I was quite overwhelmed socially. That the early-morning power loss also knocked out my CPAP and left me sick and surly on the last day didn’t help my already introverted tendencies. Nonetheless, I talked to a lot of people, attended a lot of sessions, partied a bit, played some Rock Band, and have a lot that’s percolating in my brain-meats.

There’s plenty coming up to work on in my own assigned sphere of webdev—but I’m also pretty jazzed about the Mozilla Labs projects Prism, Ubiquity, and Weave. Not sure what I can do yet, but would like to do something to help out those efforts. And maybe by the time of the next summit, I’ll still be in the Mozilla sphere and will have met and helped a few more Mozillans with whom I can connect face-to-face.

There was also a lot of talk about the future and continuing mission of Mozilla, all very inspirational and telling me that this is the center of things where I’ve always wanted to be. Now, I just have to work hard to make sure they’re not sorry they hired me! I’m running much slower than I’d like, since I feel I have a lot to catch up on while in the midst a lot of disruption and change—between the intensity of the last few months (or even the last year) and readjusting to being back in the Mitten with homeownership all anew and many plans having taken unexpected turns.

But, things are shaping up in a sort of too-good-to-be-true configuration, and I suspect I’ll be just fine if I sharpen up a bit and roll with the changes.

Putting the Sexy into Firefox Theme Browsing

l.m.orchard — Mon, 16 Jun 2008 20:07:46 +0000

As mentioned back in week 3, I’d started work on bug 419647 to “add a sexy theme browser” to addons.mozilla.org.

Well, I’m not sure about my success in imbuing it with the required sexiness, but it’s at least been noticed by someone. :)

Firefox 3 Download Day Mega Widget

l.m.orchard — Mon, 16 Jun 2008 19:55:04 +0000

Update: Oh, and rumor has it that this widget will switch to reporting on downloads, rather than pledges, once the main event has begun.

Update 2: It didn’t quite go like clockwork, but this widget is now showing estimated downloads by countries, rather than pledges.

Thanks to the completion of bug 435967, I can offer this totally unofficial hack of a mega widget (better late than never):

If you’d like, you can include this on your own site with a Copy-and-Paste of the following:

This is a total 2-hour cut, paste, reformat, and slight rejigger of Kent Brewster’s work on Content Syndication with Case-Hardened JavaScript. Hopefully it works, because I’m releasing early before I’ve had a chance to check it out on anything besides the browsers in my lap.

Week 3 at Mozilla

l.m.orchard — Fri, 23 May 2008 05:04:20 +0000

So, it’s getting to the end of my third week at Mozilla, and I’m a part of the Planet now—hooray! Having gotten a membership into that club, I feel like I should start making some noise about what I’m doing at work. Having stayed mostly quiet about day job affairs thus far in my career, it’s going to take a bit to get used to a place as open as Mozilla.

Being a noob, I haven’t started anything earthshaking yet. But, I have gotten a couple of starter bugs thrown my way:

Bug 395271 – Use memcache to cache output pages for non logged in users

SUMO is support.mozilla.org, a humongous and mostly volunteer-driven support effort for Mozilla products. I’ve never really been to the site before myself, so this bug is an iceberg-tip intro to the effort for me. I’m wading chest deep into TikiWiki and plonking memcached into the middle of it to try to make knowledge base wiki page views a lot less expensive.

Oh, and the source I’m working on is in subversion. Weird. Like, you could go look at it right now, and tell me how bad my code is.
Bug 419647 – Add a sexy theme browser

AMO is addons.mozilla.org, another humongous effort to support distribution and developers of extensions for Firefox and more. This is a site I’ve been to plenty of times, but never as an extension developer. And so, here’s another opportunity to start wading into the deep end. For this particular bug, the goal is to work up a presentation of themes more easily scanned visually.

Nothing checked into SVN for this one yet, so you’ll have to withhold ridicule for a little bit yet.

I’m really working on squashing my nerd fanboy tendencies. Because, I remember downloading the original Mozilla Open Source release, staying home from work to compile it on Windows with Visual Studio, and getting just one or two page views out of it before it fell over and caught on fire. And of course, long before that, I remember using the original lizard in monochrome on a Sun workstation, freaking out over everything and looking up Earth 2 episode guides.

So, although I’m kinda subdued in general right now—subdued as in beat about the head and shoulders—I’ve got a serious amount of breathlessness going on while trying hard to just kinda be nonchalant. :)

Go Midwest, Young Man!

l.m.orchard — Thu, 15 May 2008 01:01:37 +0000

Reminiscent of this time almost two years ago, it’s been a busy period so far. I’ve been working on another book, entitled Professional JavaScript Frameworks, and have changed jobs twice since leaving Yahoo! in early April.

I think I’m done bouncing around now, though: As you may or may not already know, I’ve started working for the Mozilla Corporation—I’ve got a username and everything! I’m a little overwhelmed at the moment by changes and drinking from a new firehose, so my enthusiasm may not yet be readily apparent. But, remember that I’m a complete web geek—and it’s hard to get closer to web geekery than this.

But, one of the nicest things about this new Mozilla gig is that I’m going to start telecommuting. And the reason that’s nice is because—and here’s the next big thing—my wife and I have bought a beautiful house in Livonia, Michigan, and we’re moving back to the Midwest in a month and some change.

Why? Because, after almost two years out here in the valley, we’ve discovered that being away from family and old friends while trying to make new friends and adjust to a very different locale was a lot harder than first imagined. And, well, it would’ve been much longer than we’d've liked before we could have afforded a house at all—let alone something anything like what we’ll be enjoying back in Michigan.

The thing is, though, I’ve still got a lot of love for the Bay Area and its goings on—I’ve been pining for this place since at least the age of eight, after all. And, we have made a few good friends out here, despite the difficulties we’ve experienced.

So luckily, this Mozilla gig looks like the ideal thing. I’m hoping it will ensure regular return visits to enjoy SuperHappyDevHouses, the scent of star jasmine in the summer, and amazing cloudless skies lasting for days.

But, on the other hand—although I’m certainly not relishing the thought of readjusting to cold, clouds, and snow in a few months—I’m getting excited about the prospects of being back in southeastern Michigan. Our house will be pretty close to both Ann Arbor and Detroit, and it seems like some interesting things have started warming up since we left. Also, I suspect (and hope) we’ll discover a lot of friends and like-minded associates in short order upon our return.

Lots of change. Very busy. Not a little exciting. But, I’m hopeful that things are going to get a lot better very soon.