mykzilla

Mozilla Status Board Text is Markdown

2011-10-17T10:38:00.001-07:00

It isn't documented anywhere that I can find, but Benjamin Smedberg's handy Mozilla Status Board tool parses status text as Markdown, which is how I added a Didn't header to the Done section of my status update with all the things I planned to do last week but didn't make happen. (The Done, Next, and Coordination headers are all H4s, so I prepended four hash marks to #### Didn't to make it the same size).

(Note that [Markdown-style links](http://daringfireball.net/projects/markdown/basics) don't work and cause the entire section in which they appear to remain unparsed. However angle-bracketed URLs, as recommended by RFC 3986 <http://labs.apache.org/webarch/uri/rfc/rfc3986.html#delimiting>, work when added to the ends of lines. And "bug ###" references are auto-linkified.)

to all the bugs I've filed before

2011-09-16T08:32:00.001-07:00

The first bug I filed was marked as duplicate; the second was worksforme (although Chris Petersen could reproduce it before he couldn't anymore); and the third was invalid (it was the spec, not the code, that was errant). The fourth is the first that was fixed.

"Next/Previous Tab" Keyboard Shortcuts on Windows

2011-09-09T17:01:00.000-07:00

On my Windows laptop, I use the following four programs with tabbed interfaces on a regular basis:

Firefox
Thunderbird
Instantbird
Komodo IDE

(I'd love to have tabs in my Windows terminal app of choice, Mintty, but its developer thinks tabs should be implemented at the window manager level.)

Unlike on my Mac, all those programs implement the same keyboard shortcut for switching to the previous/next tab, and it's a simple one with just a two-key chord: Control + PageUp / PageDown.

Ha!

"Next/Previous Tab" Keyboard Shortcuts on Mac

2011-09-08T17:03:00.001-07:00

On my Mac, I use the following five programs with tabbed interfaces on a regular basis:

Firefox
Thunderbird
Adium
Terminal
Komodo IDE

And those programs implement the following five different keyboard shortcuts for switching to the previous/next tab:

Control + PageUp / PageDown (Firefox, Thunderbird)
Command + LeftArrow / RightArrow (Adium)
Command + PageUp / PageDown (Komodo IDE)
Command + Shift + [ / ] (Terminal)
Command + Shift + LeftArrow / RightArrow (Terminal)

Hrm.

gitflow vs. the SDK

2011-09-07T14:25:00.000-07:00

gitflow is a model for developing and shipping software using Git. Add-on SDK uses Git, and it too has a model, which is similar to gitflow in some ways and different in others. Here's a comparison of the two and some thoughts on why they vary.

First, some similarities: both models use multiple branches, including an ongoing branch for general development and another ongoing branch that is always ready for release (their names vary, but that's a trivial difference). Both also permit development on temporary feature (topic) branches and utilize a branch for stabilization of the codebase leading up to a release. And both accommodate the occasional hotfix release in similar ways.

(Aside: gitflow appears to encourage feature branches, but I tend to agree with Martin Fowler through Paul Julius that continuously integrating with a central development branch is preferable.)

Second, some differences: the SDK uses a single ongoing stabilization branch, while gitflow uses multiple short-lived stabilization branches, one per release. And in the SDK, stabilization fixes land on the development branch and then get cherry-picked to the stabilization branch; whereas in gitflow, stabilization fixes land on the stabilization branch and then get merged to the development branch.

(Also, the SDK releases on a regular time/quality-driven "train" schedule similar to Firefox's, while gitflow may anticipate an irregular feature/quality-driven release schedule, although it can be applied to projects with train schedules, like BrowserID.)

A benefit of gitflow's approach to stabilization is that its change graph includes only distinct changes, whereas cherry-picking adds duplicate, semi-associated changes to the SDK's graph. However, a downside of gitflow's approach is that developers must attend to where they land changes, whereas SDK developers always land changes on its development branch, and its release manager takes on the chore of getting those changes onto the stabilization branch.

(It isn't clear what happens in gitflow if a change lands on the development branch while a release is being stabilized and afterward is identified as being wanted for the release. Perhaps it gets cherry-picked?)

Overall, these models seem fairly similar, and it wouldn't be too hard to make the SDK's be essentially gitflow. We would just need to stipulate that developers land stabilization fixes on the stabilization branch, and the release manager's job would then be to merge that branch back to the development branch periodically instead of cherry-picking in the other direction.

However, it isn't clear to me that such a change would be preferable. What do you think?

Administer Git? Get a job!

2011-08-21T22:51:00.000-07:00

As I mentioned recently, Git (on GitHub) has become a popular VCS for Mozilla-related projects.

GitHub is a fantastic tool for collaboration, and the site does a great job running a Git server, but given the importance of the VCS, and because Mozilla's automated test machines don't have access to servers outside the Mozilla firewall, Mozilla should run its own Git server (that syncs with GitHub, so developers can continue to use that site for collaboration).

Unfortunately, the organization doesn't have a great deal of in-house Git server administration experience, but we're hiring systems administrators, so if you grok Git hosting and meet the other requirements, send in your resume!

Why the Add-on SDK Doesn't "Land in mozilla-central"

2011-08-11T13:33:00.000-07:00

Various Mozillians sometimes suggest that the Add-on SDK should "land in mozilla-central" and wonder why it doesn't. Here's why.

The Add-on SDK depends on features of Firefox (and Gecko), and the SDK's development process synchronizes its release schedule with Firefox's. Nevertheless, the SDK isn't a component of Firefox, it's a distinct product with its own codebase, development process, and release schedule.

Mozilla makes multiple products that interact with Firefox (addons.mozilla.org, a.k.a. AMO, is another), and distinct product development efforts should generally utilize separate code repositories, to avoid contention between the projects regarding tree management, the stages of the software development lifecycle (i.e. when which branch is in alpha, beta, etc.), and the schedules for merging between branches.

There can be exceptions to that principle, for products that share a bunch of code, use the same development process, and have the same release schedule (cf. the Firefoxes for desktop and mobile). But the SDK is not one of those exceptions.

It shares no code with Firefox. Its process utilizes one fewer branch and six fewer weeks of development than the Firefox development process, to minimize the burden of branch management and stabilization build testing on its much smaller development team and testing community. And it merges its branches and ships its releases two weeks before Firefox, to give AMO and addon developers time to update addons for each new version of the browser.

Living in its own repository makes it possible for the SDK to have these differences in its process, and it also makes it possible for us to change the process in the future, for example to move up the branch/release dates one week, if we discover that AMO and addon developers would benefit from three weeks of lead time; or to ship twice as frequently, if we determine that doing so would get APIs for new Firefox features into developers' hands faster.

Finally, the Jetpack project has a vibrant community of contributors (including both organization staff and volunteers) who strongly prefer contributing via Git and GitHub, because they find it easier, more efficient, and more enjoyable, and for whom working in mozilla-central would mean taking too great a hit on their productivity, passion, and participation.

Mozilla Labs innovates not only on features and user experience but also on development process and tools, and while Jetpack didn't lead the way to GitHub, we were a fast follower once early experiments validated its benefits. And our experience since then has only confirmed our decision, as GitHub has proven to be a fantastic tool for branch management, code review/integration, and other software development tasks.

Other Mozillians agree: there are now almost two hundred members and over one hundred repositories (not counting forks) in the Mozilla organization on GitHub, with major initiatives like Open Web Apps and BrowserID being hosted there, not to mention all the Mozilla projects in user repositories, including Rust and Zamboni.

Even if we don't make mozilla-central the canonical repository for SDK development, however, we could still periodically drop a copy of the SDK source against which Firefox changes should be tested into mozilla-central. And doing so would theoretically make it easier for Firefox developers to run SDK tests when they discover that a Firefox change breaks the SDK, because they wouldn't have to get the SDK first.

But the benefit to Firefox developers is minimal. Currently, we periodically drop a reference to the SDK revision against which Firefox changes should be tested, and developers have to do the following to initiate testing:

  wget -i testing/jetpack/jetpack-location.txt -O addon-sdk.tar.bz2

  tar xjf addon-sdk.tar.bz2

  cd addon-sdk-[revision]

  source bin/activate

  cfx testall --binary path/to/Firefox/build

We can simplify this to:

  testing/jetpack/clone

  cd addon-sdk

  source bin/activate

  cfx testall --binary path/to/Firefox/build

Whereas if we dropped the source instead of just a reference to it, it would instead be the only slightly simpler:

  cd testing/jetpack/addon-sdk

  source bin/activate

  cfx testall --binary path/to/Firefox/build

Either of which can be abstracted to a single make target.

But if we were to drop source instead of a reference thereto, the drops would be larger and riskier changes. And test automation would still need to be updated to support Git (or at least continue to use brittle Git -> Mercurial mirroring), in order to run tests on SDK changes, which periodic source drops do not address.

Now, this doesn't mean that no SDK code will ever land in mozilla-central.

Various folks have discussed integrating parts of the SDK into core Firefox—including stable API implementations, the module loader, and possibly the bootstrapper—to reduce the size of addon packages, improve addon startup times, and decrease addon memory consumption. I have written a very preliminary draft of a feature page describing this work, although I do not think it is a high priority at the moment, relative to the other priorities identified in the Jetpack roadmap.

And Dietrich Ayala recently suggested integrating the SDK into core Firefox for use by core features, by which he presumably also means the API implementations/module loader/bootstrapper rather than the command-line tool for testing and packaging addons.

Nevertheless, I am (and, I suspect, the whole Jetpack team is) even open to discussing integration of the command-line tool (or its replacement by a graphical equivalent), merging together the two products, and erasing the distinction between them, just as Firefox ships with core features for web development. We've even drafted a feature page for converting the SDK into an addon, which is a big step in that direction.

But until that happens, farther on up the road, the SDK is its own product that we develop with its own process and ship on its own schedule. And it has good reason to live in its own repository, and a Git one at that, as do the many (and growing number of) other Mozilla projects using similar processes and tools, which our community-wide development, collaboration, and testing infrastructure must evolve to accommodate.

SDK Training and More at Add-on-Con

2010-12-02T11:07:00.001-08:00

Next Wednesday, December 8, I'll be at Add-on-Con.

In the morning, I'll conduct a training session introducing Mozilla's new Add-on SDK, which makes it faster and easier to build Firefox add-ons. Afterwards, I'll be around and about to discuss add-ons and answer questions about the SDK and add-on development generally.

Lots of other Mozilla folks will also be on hand over the course of the two-day conference, including Dave Townsend, Jorge Villalobos, Jeniffer Boriss, Mark Finkle, and Justin Scott. A rockin' time should be had by all. Join us!

Further Adventures In Git(/Hub)ery

2010-11-27T20:47:00.001-08:00

This evening I decided to check if there were any outstanding pull requests for the SDK repository (to which I haven't been paying attention).

There were! The oldest was pull request 29 from Thomas Bassetto, which contains two small fixes (first, second) to the docs.

So I fetched the branch of his fork in which the changes reside:

$ git fetch https://github.com/tbassetto/addon-sdk.git master

But that branch (and the fork in general) is a few weeks out-of-date, so "git diff HEAD FETCH_HEAD" showed a bunch of changes, and it was unclear how painful the merge would be.

Thus I decided to try cherry-picking the changes, my first time using "git cherry-pick".

The first one went great:

$ git cherry-pick 8268334070d03a896d5c006d1b4db94d4cb44b17
Finished one cherry-pick.
[master ceadb1f] Fixed an internal link in the widget doc
1 files changed, 1 insertions(+), 1 deletions(-)

Except that I realized afterward I hadn't added "r,a=myk" to the commit message. So I tried "git commit --amend" for the first time, which worked just fine:

$ git commit --amend
[master 2d674a6] Fixed an internal link in the widget doc; r,a=myk
1 files changed, 1 insertions(+), 1 deletions(-)

Next time I'll remember to use the "--edit" flag to "git cherry-pick", which lets one "edit the commit message prior to committing."

The second cherry-pick was more complicated, because I only wanted one of the two changes in the commit (in my review, I had identified the second change as unnecessary); and, as it turned out, also because there was a merge conflict with other commits.

I started by cherry-picking the commit with the "--no-commit" option (so I could remove the second change):

$ git cherry-pick --no-commit 666ad7a99e05e338348dfc579d5b1f75e8d3bb1b
Automatic cherry-pick failed. After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result.
When commiting, use the option '-c 666ad7a' to retain authorship and message.

The conflict was trivial, and I knew where it was, so I resolved it manually (instead of trying "git mergetool" for the first time), removed the second change, added the merged file, and committed the result, using the "-c" option to preserve the original author and commit message while allowing me to edit the message to add "r,a=myk":

$ git add packages/addon-kit/docs/request.md
$ git commit -c 666ad7a
[master 774d1cb] Completed the example in the Request module documentation; r,a=myk
1 files changed, 1 insertions(+), 0 deletions(-)

Then I used "gitg" and "git log master ^upstream/master" to verify that the commits looked good to go, after which I pushed them:

$ git push upstream master
[git's standard obscure and disconcerting gobbledygook]

Finally, I closed the pull request with this comment that summarized what I did and provided links to the cherry-picked commits.

It would have been nice if the cherry-picked commit that didn't have merge conflicts (and which I didn't change in the process of merging) had kept its original commit ID, but I sense that that is somehow a fundamental violation of the model.

It would also have been nice if the cherry-picked commit messages had been automatically annotated with references to the original commits.

But overall the process seemed pretty reasonable, it was fairly easy to do what I wanted and recover from mistakes, and the author, committer, reviewer, and approver are clearly indicated in the cherry-picked commits (first, second).

[Also posted to the discussion group.]

More Git/Hub Workflow Experiences

2010-11-27T20:39:00.001-08:00

After posting about my first Git/Hub workflow experiences, I got lots of helpful input from various folks, particularly Erik Vold, Irakli Gozalishvili, and Brian Warner, which led me to refine my process for handling pull requests:

From the "how to merge this pull request" section of the pull request page (f.e. pull request 34), copy the command from step two, but change the word "pull" to "fetch" to fetch the remote branch containing the changes without also merging it:

git fetch https://github.com/toolness/jetpack-sdk.git bug-610507
Use the magic FETCH_HEAD reference to the last fetched branch to verify that the set of changes is what you expect:

git diff HEAD FETCH_HEAD

(The exact syntax here may need some work; HEAD..FETCH_HEAD? three dots?)
Merge the remote branch into your local branch with a custom commit message:

git merge FETCH_HEAD --no-ff -m"bug 610507: get rid of the nsjetpack package; r=myk"
Push the changes upstream:

git push upstream master

I like this set of commands because it doesn't require me to add a remote, I can copy/paste the fetch command from GitHub (being careful not to issue the pull before I change it to a fetch), and I always type the same FETCH_HEAD reference to the remote branch in step three.

However, I wish the merge commit page explicitly referenced the specific commits that were merged. It does mention that it's a branch merge, it isn't obvious how to get from that page to the pages for the commits I merged from the branch.

"git log --oneline --graph", gitg, and gitk do give me that information, though, so I'm ok on the command line, anyway.

[More discussion can be found in the discussion group thread.]

Git/Hub Workflow Experiences

2010-11-12T18:55:00.000-08:00

The Jetpack project recently migrated its SDK repository to Git (hosted on GitHub), and we've been working out changes to the bug/review/commit workflow that GitHub's tools enable (specifically, pull requests).

Here are some of my initial experiences and my thoughts on them (which I've also posted to the Jetpack discussion group).

Warning: Git wonkery ahead, with excruciating details. I would not want to read this post. I recommend you skip it. ;-)

Part 1: Wherein I Handle My First Pull Request

To fix some test failures, Atul submitted GitHub pull request 33, I reviewed the changes (comprising two commits) on GitHub, and then I pushed them to the canonical repository via the following set of commands:

git checkout -b toolness-4.0b7-bustage-fixes master
git pull https://github.com/toolness/jetpack-sdk.git 4.0b7-bustage-fixes
git checkout master
git merge toolness-4.0b7-bustage-fixes
git push upstream master

That landed the two commits in the canonical repository, but it isn't obvious that they were related (i.e. part of the same pull request), that I was the one who reviewed them, or that I was the one who pushed them.

Part 2: Wherein I Handle My Second Pull Request

Thus, for the fix for bug 611042, for which Atul submitted GitHub pull request 34, I again reviewed the changes (also comprising two commits) on GitHub, but then I pushed them to the canonical repository via this different set of commands (after discussion with Atul and Patrick Walton of the Rust team):

git checkout -b toolness-bug-611042 master
git pull https://github.com/toolness/jetpack-sdk.git bug-611042
(There might have been something else here, since the pull request resulted in a merge; I don't quite remember.)
git checkout master
git merge --no-ff --no-commit toolness-bug-611042
git commit --signoff -m "bug 611042: remove request.response.xml for e10s compatibility; r=myk" --author "atul"
git push upstream master

Because Atul's pull request was no longer against the tip (since I had just merged those previous changes), when I pulled the remote bug-611042 branch into my local toolness-bug-611042 branch (step 2), I had to merge his changes, which resulted in a merge commit.

Merging the changes to my local master with "--no-ff" and "--no-commit" (step 5) then allowed me to commit the merge to my master branch manually (step 6), resulting in another merge commit.

For the second merge commit, I specified "--signoff", which added "Signed-off-by: Myk Melez " to the commit message; crafted a custom commit message that included "r=myk"; and specified '--author "atul"', which made Atul the author of the merge.

I dislike having the former merge commit in history, since it's extraneous, unuseful details about how I did the merging locally before I pushed to the canonical repository. I'm not sure how to avoid it, though.

On the other hand, I like having the latter merge commit in history, since it provides context for Atul's two commits: the bug number, the fact that the changes were reviewed, and a commit message that describes the changes as a whole.

I'm ambivalent about --signoff vs. adding "r=myk" to the commit message, as they seem equivalentish, with --signoff being more explicit (so in theory it might form part of an enlightened workflow in the future), while "r=myk" is simpler.

And I dislike having made Atul the author of the merge, since it's incorrect: he wasn't the author of the merge, he was only the author of the changes (for which he is correctly credited). And if the merge itself caused problems (f.e. I accidentally backed out other recent changes in the process), I would be the one responsible for fixing those problems, not Atul.

Part 3: Pushing Patches

In addition to pull requests, one can also contribute via patches. I've pushed a few of these via something like the following set of commands:

git apply patch.diff
git commit -a -m "bug : ; r=myk" --author ""
git push upstream master

That results in a commit like this one, which shows me as the committer and the patch author as the author. And that seems like a fine record of what happened.

Part 4: To Bug or Not To Bug?

One of the questions GitHub raises is whether or not every change deserves a bug report. And if not, how do we differentiate those that do from the rest?

I don't have the definitive answers to these questions, but my sense, from my experience so far, is that we shouldn't require all changes to be accompanied by bug reports, but larger, riskier, time-consuming, and/or controversial changes should have reports to capture history, provide a forum for discussion, and permit project planning; while bug reports should be optional for smaller, safer, quickly-resolved, and/or non-controversial changes.

My Recent Jetpack Presentations

2010-07-15T14:22:00.000-07:00

The last few weeks have been presentation-heavy.

First, I gave a presentation about the Jetpack project (past accomplishments, present status, future plans) at the 2010 London Mozilla Add-ons Workshop (MAOW), including a demo of using Add-on Builder to build an add-on in five minutes.

Then I reprised the Add-on Builder demo as part of the opening day keynote at the Mozilla Summit, where it got a great reception. You can watch it in this Youtube video.

Finally, I gave an updated version of the MAOW presentation on the third day of the summit. The slides are available in OpenDocument and PDF formats, and Jetpack presentation materials generally are all available from the Jetpack Presentations wiki page.

This blog has moved

2010-03-05T23:03:00.001-08:00

This blog is now located at http://mykzilla.blogspot.com/.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
http://mykzilla.blogspot.com/feeds/posts/default.

The Skinny on Raindrop's Mailing List Extensions

2009-11-17T17:26:00.000-08:00

Raindrop is an exploration of messaging innovation that strives to intelligently assist people in managing their flood of incoming messages. And mailing lists are a common source of messages you need to manage. So, with assistance from the Raindrop hackers, I wrote extensions that make it easier to deal with messages from mailing lists.

Their goal is to soothe two particular pain points when dealing with mailing lists: grouping their messages together by list and unsubscribing from them once you're no longer interested in their subject matter.

This post explains how the extensions do this; touches on some aspects of Raindrop's message processing and data storage models; and speculates about possible future directions for the extensions.

Raindrop Extensibility

Raindrop is being built with the explicit goal of being broadly and deeply extensible, and it includes a number of APIs for adding and modifying functionality. The mailing list enhancements comprise two related extensions, one in the backend and one in the user interface.

The backend extension plugs into Raindrop's incoming message processor, intercepting incoming email messages and extracting info about the mailing lists to which they belong. It also handles much of the work of unsubscribing from a list.

The frontend extension plugs into Raindrop's Inflow application, modifying its interface to show you the most recent mailing list messages at a glance, group mailing list conversations together by list, and provide a button you can press to easily unsubscribe from a mailing list.

Message Processing and Data Storage

Before getting into how the extensions work, it's useful to know a bit about how Raindrop processes and stores messages.

Raindrop stores information using CouchDB, a document-centric database whose principal unit of information storage and retrieval is the document (the equivalent of a record in SQL databases). Documents are just JSON blobs that can contain arbitrary name -> value pairs (unlike SQL records, which can only contain values for predeclared columns).

To distinguish between different kinds of documents, Raindrop assigns each a schema (similar to a table in SQL parlance) that describes (and may one day constrain) its properties. The rd.msg.email schema is the primary schema representing an email message, while the rd.mailing-list is the schema representing a mailing list, and the rd.msg.email.mailing-list is a simple schema that associates messages with their lists.

(In an SQL database, rd.msg.email and rd.mailing-list would be tables whose rows represent email messages and mailing lists, while rd.msg.email.mailing-list would be a table whose rows map one to the other.)

Note that there's a many-to-one relationship between messages and lists, since messages belong to a single list, although lists contain many messages, so rd.msg.email.mailing-list isn't strictly necessary. Its list-id property (which identifies the list to which the message belongs) could simply be a property of rd.msg.email docs (or, in SQL terms, a foreign key in the rd.msg.email table).

But putting it into its own document has several advantages. First, it improves robustness, as it reduces the possibility of conflicts between extensions and core code writing to the same documents.

It also improves write performance, as it's faster to add a document than to modify an existing one (although index generation and read performance can be an issue).

Finally, it improves extensibility, because it makes it possible to write an extension that extends the backend mailing list extension.

That's because Raindrop's incoming message processing model allows extensions to observe the creation of any kind of document, including those created by other extensions.

So just as the mailing list extension observes the creation of rd.msg.email documents, another extension can observe the creation of rd.msg.email.mailing-list documents and process them further in some useful way. If the mailing list extension simply modified the original document instead of creating its own, that would require some additional and more complicated API.

The Backend Extension

The primary function of the backend extension is to examine every incoming message and dress the ones from mailing lists with some additional structured information that the frontend can use to organize them.

Backend extensions are accompanied by a JSON manifest that tells Raindrop what kinds of incoming documents it wants to intercept. The mailing list extension's manifest registers it as an observer of incoming rd.msg.email documents, which get created when Raindrop retrieves an email message:

"schemas" : {
  "rd.ext.workqueue" : {
      "source_schemas" : ["rd.msg.email"],
...

The extension itself is a Python script with a handler function that gets passed the rd.msg.email document and looks to see if it contains a List-ID header (or, in certain cases, another identifier) identifying the mailing list from which the message comes:

def handler(message):
  ...
  if 'list-id' in message['headers']:
      # Extract the ID and name of the mailing list from the list-id header.
      # Some mailing lists give only the ID, but others (Google Groups,
      # Mailman) provide both using the format 'NAME <id>', so we extract them
      # separately if we detect that format.
      list_id = message['headers']['list-id'][0]
  ...

If it doesn't find a list identifier, it simply returns, and Raindrop continues processing the message:

if not list_id:
    logger.debug("NO LIST ID; ignoring message %s", message_id)
    return

Otherwise, it calls Raindrop's emit_schema function to create an rd.msg.email.mailing-list document linking the message document to an rd.mailing-list document representing the mailing list:

emit_schema('rd.msg.email.mailing-list', { 'list_id': list_id })

In this function call, rd.msg.email.mailing-list is the type of document to create, while { 'list_id': list_id } is the document itself, written as Python that will get serialized to JSON.

A document created inside a backend extension like this automatically gets a reference to the document the extension is processing (i.e. the rd.msg.email document), so the only thing it has to explicitly include is a reference to the list document, in the form of a list_id property whose value is the list identifier.

The extension also checks if there's an rd.mailing-list document in the database for the mailing list itself, and if not, it creates one, populating it with information from the message's List-* headers, like how to unsubscribe from the list. Otherwise, it updates the existing mailing list document if the message's List-* headers contain updates.

The Frontend Extension

The frontend extension uses the information extracted by the backend to help users manage mailing lists in the Inflow application.

It adds a widget to the Home view that shows you the last few messages from your lists at the bottom of the page, so you can keep an eye on those messages without having to give them your full attention:

It adds a list of your mailing lists to the Organizer widget:

And when you click on the name of a list, it shows you its conversations in the conversation pane:

In traditional mail clients, users who want to break out their list messages into separate buckets like this typically have to create a folder for each list to contain its messages and then a filter for each list to move incoming list messages into the appropriate folders. The extension does this for you automatically!

Finally, while viewing list conversations, if the extension knows how to unsubscribe you from the list, it displays an Unsubscribe button:

Pressing the button (and then confirming your decision) unsubscribes you from the list. You don't have to do anything else, like remembering your username/password for some web page, sending an email, or confirming your request with the list admin. The extensions handle all those details for you so you don't have to know about them!

List Unsubscription

In case you do want to know the details, however, it goes like this...

First, the frontend extension sends a message to the list's admin address requesting unsubscription, with a certain command (like "unsubscribe") in the subject or body of the message (lists often specify exactly what command to send in the mailto: link they include in the List-Unsubscribe header):

From: Jan Reilly 
To: wasbigtalk-admin@example.com
Subject: unsubscribe

Then the server responds with a message requesting confirmation of the request, often putting a unique token into the Subject or Reply-To header to track the request:

From: wasbigtalk-admin@example.com
To: jan@example.com
Subject: please confirm unsubscribe from wasbigtalk (4bc3b7e439fd)

Hello jan@example.com,

We have received a request to unsubscribe you from wasbigtalk.
Please confirm this request to unsubscribe by replying to this email.
...

Then the backend extension responds with a message confirming the request that includes the unique token:

From: jan@example.com
To: wasbigtalk-admin@example.com
Subject: Re: please confirm unsubscribe from wasbigtalk (4bc3b7e439fd)

Finally, the server responds with a message confirming that the subscriber has, indeed, been unsubscribed:

From: wasbigtalk-admin@example.com
To: jan@example.com
Subject: you have been unsubscribed from wasbigtalk

Hello jan@example.com,

Your unsubscription from wasbigtalk was successful.
...

At this point, the backend extension marks the list unsubscribed in the database, and the frontend extension marks it unsubscribed in the user interface.

This process matches the way much mailing list server software works, although there are daemons in the details, so the extensions have to be programmed to support each server individually.

Currently, they know how to handle Google Groups and Mailman lists. Majordomo2 (used by the Bugzilla and OpenBSD projects, among others) is not supported, because it doesn't send List-* headers (alhough supposedly it can be configured to do so). The W3C's list server is not yet supported, although it does send List-* headers, and support should be fairly easy to add.

Note that some of the processing the extension does is (locale-dependent) "screen"-scraping, as Google Groups and Mailman don't consistently identify the list ID and message type in some of their correspondence. In the long run, hopefully server software will improve in that regard. Perhaps someone can spearhead an effort to make it so?

The Future

The extensions' current features fit in well with Raindrop's goal of helping people better handle their flood of incoming messages. But there is surely much more they could do to help in this regard.

Besides general improvements to reliability and robustness--like support for additional list servers and handling of localized admin messages--they could let you resubscribe to a mailing list from which you've unsubscribed. And perhaps they could automatically fetch the messages you missed while you were away. Or even retrieve the entire archive of a list to which you're subscribed, so you can browse the archive in Raindrop!

What bugs you about mailing lists? And how might Raindrop's mailing list extensions make them easier (and even funner) to use?

Building/Releasing Personas

2009-11-04T15:58:00.001-08:00

Want to know how a popular extension like Personas gets built and released? Neither do I! Yet I know anyway. And I've written it down for your edification! So check it out.

Makefile for building/distributing extensions

2009-10-12T19:32:00.001-07:00

I've written a Makefile to help build and distribute Personas and Snowl. It automates the process of generating manifests; packaging the extension into a JAR and a XPI; and, for a "development" distribution channel, autogenerating successive version numbers and rsyncing the builds and update.rdf file to a distribution server.

The file makes it easy for me to update the latest development build of Personas after checking in a fix via:

make build channel=dev make package channel=dev make publish

For release builds, it's:

make build channel=rel make package channel=rel [manually upload to AMO]

And when I just want to test locally, I can build and install to a local profile:

make build make install profile=~/dev-profile firefox -profile ~/dev-profile

Or I can package the build and install via Firefox's Add-ons Manager:

make build make package [manually install via Firefox's Add-ons Manager]

Because I reuse it for multiple projects, project-specific variables are defined in a separate client.mk file. If you have similar needs and would find it useful, you are welcome to it!

Just grab the Makefile, see client.mk for the variables you should define, and check out the Personas source directory for the general layout that the Makefile handles as well as the install.rdf.in, chrome.manifest.in, and update.rdf.in templates from which their respective files are built.

Notes:

It's originally based on Weave's top-level Makefile, although it doesn't currently support the binary components that Weave's Makefile builds.
It assumes a directory structure in which content/, locale/, and skin/ directories are at the top level of the source directory (not within a chrome/ subdirectory).
It currently builds in the source directory rather than in an object directory, which means it can leave old install.rdf, chrome.manifest, and chrome.jar files around, so sometimes I need to make clean && make build to get rid of the ones I previously built (f.e. for a release build whose chrome files are archived) and generate new ones for continued development.
For Personas, I use a defaults/preferences/prefs.js.in template to generate prefs that contain the Mercurial revision ID (so I can identify the version of code in a development build with which someone is reporting problems) and the distribution channel (which the extension uses to suppress the "You've been updated!" page for the "dev" channel, since that would get annoying fast).

Personas for Email Messages

2009-08-29T07:54:00.000-07:00

Here's a thought (I had in the middle of a dream about brightly garbed superheroes): use Personas to style email messages in Thunderbird! It'd be a simple way to easily add some style to your messages to friends and family, highlighting your current mood, your perennial interests, or the subject of the message.

A ~~dramatization~~ mockup:

There are some tricky issues, like how to select a background color for the message that blends in attractively with the bottom of the header image. And it's not clear if the footer image is useful in this case.

But overall the idea seems quite promising. What do you think? And, if you're a Mozilla extension hacker (or would like to become one), would you be interested in prototyping it?

The Problems With Pagination

2009-04-23T08:15:00.000-07:00

Many web sites and applications paginate their content. Often this makes them harder to use.

Partly it's because site-provided pagination interacts poorly with the browser's built-in scrolling, because the content on any given web page usually takes up more than one vertical screen of space, and you have to jump back and forth between site pagination and browser scrolling, hunting down their controls each time you do so.

Sites compound this problem by moving their pagination controls around, so you can't leave your mouse over the Next Page button and assume you can simply click the mouse button repeatedly to jump to subsequent pages.

And pagination control click targets are small, which makes them hard to hit. Page-specific targets are often a single number (1, 2, 3), while the Next Page target is sometimes a single character (>).

Finally, pagination confounds searching through content using a browser's Find in Page feature, since it requires you to switch back and forth between searching for the content on the current page and navigating to the next one until you find the text you're looking for (and beyond, if you're looking for multiple occurrences of it).

And it similarly confounds any other activity in which you want to engage with all the content in an application, like when I wanted to turn off tracebacks/pingbacks for all 56 posts in a Wordpress blog, which is a six step process, and I had to repeat those six steps four times each because Wordpress's list of posts only lets me see 15 at a time.

Nevertheless, there are legitimate uses for pagination:

sites whose content is computationally intensive to generate (like search engines) use it to reduce load and cost;
those with large quantities of content that strains server, client, and network resources to display all at once (search engines again, the Personas gallery) use it to improve responsiveness;
those whose content cannot usefully be browsed in its entirety much of the time (search engines a third time, messaging applications) use it to reduce the cognitive overload of providing all their content at once;
and those with an ad-based revenue model (you guessed it, search engines, but also online news and many other sites) use it to show more ads.

For those kinds of sites, pagination makes sense, although doing it right still matters, like giving its controls large click targets and putting them in the same place on every page.

And, for content that spills across multiple screens, including the pagination controls at both the top and bottom of the content, the two scroll positions at which users often find themselves when they want to change pages; or positioning them absolutely, so they're always visible; or only loading a screenful of content at a time, so users never have to both page and scroll; or using endless/infinite scrolling.

Are there even better approaches, and are there ways for the web platform to support them so that web sites don't have to roll their own? Perhaps browsers and servers could collaborate to provide content in screenfuls with integrated scrolling and paging controls that play well together and don't change from site to site.

What do you think?

syntaxes for iterating arrays in JavaScript

2009-04-16T18:17:00.001-07:00

JavaScript lets you iterate arrays using the for each...in statement:

for each (var item in [1, 2, 3]) alert(item);

JavaScript 1.6 added the Array.forEach method:

[1, 2, 3].forEach(function(item) { alert(item) });

I've always preferred Perl's statement modifiers, though, for the popular English-like order of their clauses ("do this for each of those"):

print $_ foreach (1, 2, 3);

JavaScript 1.7 added array comprehensions for array initialization:

var squares = [item * item for each (item in [1, 2, 3])];

I just realized I can (ab)use comprehensions to iterate arrays with Perl-like syntax by throwing away the result:

[alert(item) for each (item in [1, 2, 3])];

I can iterate object properties the same way:

var obj = { foo: 1, bar: 2, baz: 3 };
[alert(name + "=" + obj[name]) for (name in obj)];

Sweet!

Snowl Integration with Places

2009-04-09T15:00:00.000-07:00

alta88 has recently done a bunch of work to integrate Snowl with Places. His initial efforts have focused on getting sources and people into Places, as he describes in this post to the discussion forum.

This will make the list of collections in the next version of Snowl work like Firefox's list of bookmarks in the Bookmarks Sidebar, and sources/people will also show up in the AwesomeBar:

Snowl doesn't yet register the snowl: protocol, however, so selecting those items doesn't do anything (yet). What do you think it should do?

And what additional Places-backed features would be useful?

(Picking up on something dietrich said on Twitter last week, I'd love to see Places get populated with tweets that reference a URL, setting the title of the Places entry to the content of the tweet, so you can use the AwesomeBar to find that site you saw last week in a tweet, as other folks have done with Delicious.)

Snowl development builds

2009-04-07T16:09:00.002-07:00

I've created a distribution channel to get Snowl changes out to its testing community faster. I'll push development snapshots to the channel on a regular basis as significant fixes are committed (or perhaps nightly, if I can automate the process).

Once you install a development build, Firefox will automatically check for newer ones and prompt you to update when it finds one, just as it does for the release builds on AMO.

This is truly the slicing edge. If you use these builds, be prepared for the possibility of regressions and bustage. On the other hand, you'll also get to test new features earlier, like alta88's Places integration work.

Install the latest development build, then discuss it and report bugs you find. (If you don't want to be on the slicing edge, try the latest stabler release instead.)

ISO simple open web image editor

2009-04-07T00:24:00.000-07:00

Is there a simple open web image editor? I know about Pixlr, Picnik, and Aviary, but those all use Flash. It seems like it should be possible to make one using Canvas and other modern open web technologies.

In addition to using it for simple photo manipulations, I'd like one that can be embedded into other applications, like Personas (to make it easy for users to make and refine their own personas) and image hosting sites (so users don't have to go to a separate website and import their images to edit them).

In other words, I want the web-based image editing equivalent of Gecko+Firefox: a great open-source image rendering and editing engine with a flagship product that demonstrates its capabilities and an API for embedding it into other applications.

Is there such a thing? Does anyone want to create one?

The Extension Bootcamp Tutorial

2009-04-06T11:23:00.001-07:00

A few weeks ago, as part of Mozilla Labs' Design Challenge, I taught a tutorial on extension development. My goal was to impart the minimum necessary information to build a simple extension using modern best practices. I called it Extension Bootcamp: Zero to "Hello world!" in 45 Minutes.

The tutorial, which borrowed from other ones (including my ancient Tinderstatus tutorial, the venerable Building an Extension, and the new Firefox addons developer guide), covered:

what extensions are, what they can do, and what they're made of;
how to configure your development environment on Windows, Mac OS X, or Linux;
how to construct an extension, including required files and directory structure;
how to package and test your extension;
a simple extension that inserts XUL into the main browser window via an overlay, styles it with CSS, listens for and responds to a DOM event on it using JavaScript, and localizes its strings with both a DTD and a properties file.

It explicitly excluded:

archiving chrome files into a JAR archive (valuable for large, popular, and stable extensions, but not worth the added complexity for the rest);
developing XPCOM components (most extensions should use JavaScript modules instead);
putting CSS/image files into a separate skin package (Firefox doesn't ship with two themes, which was the original impetus for segregating these files thusly, and most extensions don't support third-party themes, so this is unnecessary).

To conserve time, I didn't cover:

developing JavaScript modules;
accessing XPCOM components;
using tools and documentation to introspect and learn Mozilla code and APIs.

Developing a Firefox extension is pretty complicated, since there are so many different pieces to it, and the tutorial ended up taking two hours, including time for the students to practice each lesson on their own computers (for which my colleague Jono's assistance in fielding questions was invaluable).

The video of the tutorial, edited down to 1.5 hours, as well as the slides and accompanying files are available. If I had time to work more on this, I'd expand it to include the essential topics I didn't cover. I'd also update the Building an Extension tutorial to adopt the pedagogy of this one. If you'd like to do either of those things, please do!

Personas in Thunderbird

2009-03-31T10:18:00.002-07:00

Huang Yaoquan recently contributed a patch to make Personas work in Thunderbird! Here's Thunderbird with the Groovy Blue persona selected:

The patch requires a Thunderbird 3 beta, and it landed after the cutoff for the Personas 1.0 release, so it's not in the version on AMO, but it is in the latest development build, so give that one a spin if you're developmentally inclined, and provide feedback in the discussion forums or by filing bugs.

JSON JS module for Firefox 3.0/3.5 API compatibility

2009-03-25T18:23:00.000-07:00

I've written a JSON module to wrap the incompatible Firefox 3.0 and 3.5 JSON APIs, presenting the 3.5 API on both versions of Firefox, which is useful for extensions that support them both. Import this module to parse and stringify JSON in both 3.0 and 3.5 without having to check the host application's version each time.

Note: don't import this into the global namespace! If you do, you'll hork native Firefox 3.0 code that expects the 3.0 API. Instead, import it into your own object like this:

let MyExtension = {
JSON: null,
...
};
Components.utils.import("chrome://myextension/modules/JSON.js", MyExtension);
// Now MyExtension.JSON is an object implementing the Firefox 3.5 JSON API.

The module also works in Thunderbird 3.0, which uses Firefox 3.5's API (although there's no need to use it for an extension that only supports Thunderbird 3.0). I use it in Personas, which supports both Firefox 3.0 and 3.5 as well as Thunderbird 3.0.

The Firefox 3.5 JSON API is documented in the Mozilla Developer Center article Using JSON in Firefox. This JSON module is documented on Mozilla Labs' JS Modules wiki page.

Merging with Mercurial 1.0 and Meld

2009-03-18T18:32:00.000-07:00

In an earlier post, I described my experience merging changes with Mercurial 0.9.5 and Meld 1.1.5.1 on Ubuntu 8.04.

Things have changed in Ubuntu 8.10, which ships Mercurial 1.0.1. Now Meld displays your version of the file on the left, the other version on the right, and the base version (from which yours and the other are descended) in the middle.

Here it is handling the Merging conflicting changes example from the hg book:

Your job is to reconcile the conflicts between your version on the left and the other version on the right, turning your version on the left into the result of the reconciliation, which you then save to your working directory.

I understand why it can be useful to show the base version, and I think it's ok to use the same pane to show both your version and the final result (although kdiff3 provides a fourth pane beneath these three for the latter, which seems better).

But I don't understand why the base version is in the middle, given that one's primary task in this situation is to compare the differences between the two versions on either side of the window, copying changes from one to the other as needed. Putting another file in the middle just gets in the way of that process (which is presumably why kdiff3 puts the base version on the left and your version in the middle according to the screenshot in the aforementioned example in the hg book).

In fact, I frequently find myself starting a merge by copying the other version of the file into the base version in its entirety. That destroys my ability to refer to the base version, but it places the other version and my version side by side, at which point it's much easier to compare the two and edit my version accordingly:

But maybe I'm missing the point or misusing the tool, and there's some valid reason for the way Mercurial uses Meld. Can someone tell me what it is?

A XULRunner-Based Unit Test Harness

2009-02-04T17:48:00.001-08:00

Prologue

After finding a couple bugs in the Observers JS module recently, I looked around for a simple test harness to exercise it and other JS modules. Weave's (based on Mozilla's xpcshell harness) seemed promising, although it has to hack around various limitations of xpcshell.

Atul Varma had suggested some time ago that a XULRunner-based harness might make sense, so I decided to see if I could modify Weave's harness to run JS module tests using XULRunner instead of xpcshell.

Act 1

That proved doable, although some details were tricky. Sometimes I wondered whether I wouldn't have been better off reusing MochiTest, although it's heavier weight. Other times I wondered why I didn't find this bug about XULRunner-based unit tests sooner, although it's not clear that reusing the attachment in that bug would have been faster.

In any case, I got the harness working with XULRunner and wrote an initial set of tests of the Observers module. To run them, pull the jsmodules repository, change to its test/unit/ subdirectory, and run make with the location of your XULRunner executable (or set the XULRUNNER_BIN environment variable to its location):

hg clone https://hg.mozdev.org/jsmodules
cd jsmodules/test/unit/
make xulrunner_bin=/usr/bin/xulrunner

Since Firefox 3.0 comes with XULRunner, you can use any Firefox 3.0 (or newer) executable instead (except on Linux distros that ship Firefox as a XULRunner app--you have to use the XULRunner executable on those), like /Applications/Firefox.app/Contents/MacOS/firefox-bin on Mac and /c/Program\ Files/Mozilla\ Firefox/firefox.exe on Windows.

Epilogue

Once I got the harness working for jsmodules, I backported it to Weave, where it mostly works, except that IWeaveCrypto.generateKeypair (which calls PK11_GenerateKeyPair) fails, apparently because of SEC_ERROR_TOKEN_NOT_LOGGED_IN.

I have no idea why, but if you do, comment here or in bug 476539, since that's the last blocker to Weave using this harness.

Observers JS Module Improvements

2009-02-04T17:44:00.000-08:00

I've updated the Observers JS module with a number of changes. In particular, it's now possible to specify a this object when adding an observer that is a method, so instead of doing this:

let MyObserver = {
  onFoo: function(subject) {...},
  onBar: function(subject) {...},
  onBaz: function(subject) {...},
  QueryInterface: XPCOMUtils.generateQI([Ci.nsIObserver]),
  observe: function(subject, topic, data) {
    switch(topic) {
      case "foo":
        this.onFoo(subject);
        break;
      case "bar":
        this.onBar(subject);
        break;
      case "baz":
        this.onBaz(subject);
        break;
    }
  }
}

Observers.add("foo", MyObserver);
Observers.add("bar", MyObserver);
Observers.add("baz", MyObserver);

You can do this:

let MyObserver = {
  onFoo: function(subject) {...},
  onBar: function(subject) {...},
  onBaz: function(subject) {...}
}

Observers.add("foo", MyObserver.onFoo, MyObserver);
Observers.add("bar", MyObserver.onBar, MyObserver);
Observers.add("baz", MyObserver.onBaz, MyObserver);

Other changes include a couple of bug fixes and some backwards-incompatible API improvements. See the documentation for all the details (including steps to update from the previous version of the module).

Snowl Roadmap

2009-01-09T17:55:00.000-08:00

Based on Snowl's potential futures, and in line with its principles, I've put together a roadmap for its next three releases (beyond the imminent 0.2 release).

Generally, I'm aiming for six week development cycles that are that ambiguous mixture of date-, feature set-, and quality-driven, so the goal is to hit the target date with high quality implementations of the specified set of features. But work may be pushed to later releases or the schedule extended as appropriate.

Each cycle has a theme on which I'll focus my efforts, and I'll publish regular preview releases, which will be numbered with consecutive "pre[n]" suffixes (f.e. 0.3pre1, 0.3pre2).

Most of the work on the roadmap is stuff I'm planning to do myself, although it also lists tasks that other developers have expressed an interest in tackling. And it's ambitious, so I probably won't get to all of these tasks (although I'll probably do other things that come up along the way).

If you want to do something with Snowl, whether or not it's on the roadmap, check out the source code and go for it! (And let us know what you're doing so others don't duplicate your work.)

Caveat: nothing is written in stone, it's the best laid plans of mice and men, take it with a grain of salt, etc. Among other things, this roadmap doesn't account for time I may spend working on other projects, nor am I any better than other hackers at estimating the time it takes to do work I haven't already done. And the farther out the roadmap goes, the fuzzier its plans.

Also, your suggestions are welcome. Are you missing something from the roadmap? Is there something on it that shouldn't be there? Let us know!

The latest version lives on the Mozilla wiki at https://wiki.mozilla.org/Labs/Snowl/Roadmap. Currently, it looks like this:

Priorities

As with Firefox development (f.e. with Firefox 3.1 features), Snowl tasks are prioritized. For Snowl, the fuzzy prioritization scheme is:

P1: really want
P2: want
P3: nice to have

Releases

These are the target release dates for the imminent 0.2 release and the three releases after that:

0.2: Monday, January 12
0.3: Monday, March 9
0.4: Monday, April 20
0.5: Tuesday, May 26

(Note: The 0.3 cycle is eight weeks long to accommodate twoish weeks of vacation I have planned in January and February.)

0.3: simpler and smarter

Feeds

P1 expose feeds from frecent (frequent + recent) websites [atul]
P1 pick a feed automatically from among feeds with equivalent content
P1 let users subscribe to feeds by entering the location of a website
P2 automatically subscribe to feeds in live bookmarks [atul]
P2 automatically discard old feed items and tweets
P2 automatically determine how often to refresh feeds
P2 let users specify how long to retain feed items and tweets

Twitter

P1 support replying to messages
P2 support direct messages (private messages to specific users)
P2 automatically subscribe to Twitter account in browser history
P3 shorten long URLs when composing messages

Architecture/Extensibility

P1 simplify composition of messaging service implementations from Source and Target prototypes

Misc

P1 split collections view into resizable accounts/people sections [alta88]
P1 support email protocols [alta88]
P2 integrate Snowl into Thunderbird
P2 organize river view into editions
P3 use JS templates to build stream, river views

0.4: people and extensibility

People

P1 add a person-centric view
P1 automatically associate identities that represent the same person
P1 let users associate identities that represent the same person

Extensibility

P1 optimize database schema for sparse/custom attributes (f.e. username for Twitter, website URI for feeds)
P2 move OPML import/export processing into messaging service connectors so they can provide custom attributes (f.e. username for Twitter)
P2 compose subscription dialog from messaging service connector-specific overlays
P3 factor out common functionality from Feed and Twitter implementations into Source and Target prototypes

Conversations

P2 derive conversations from message metadata
P2 display messages in the contexts of the conversations to which they belong

Misc

P2 add a wordle-like view of messages

0.5: broader horizons

Feed Conversations

P1 retrieve comments on feed items automatically
P2 enable users to post comments on feed items

People

P1 consume contact info from Portable Contacts service providers
P2 provide contact info to Portable Contacts consumers

Misc

P1 support several additional messaging services/social networks

P2 support categorization of accounts and messages via tagging
P2 synchronize subscriptions to a cloud datastore
P3 synchronize all message data to a cloud datastore

Snowl Principles

2009-01-08T21:34:00.000-08:00

Over the course of working on Snowl, I've established a set of principles to guide its development. They're aspirational, but they have many practical ramifications. And while the current implementation doesn't embody them yet by a long shot, I expect it conform more and more closely to them over time.

The principles are:

feeds are a transport format, not a feature;
people and conversations are first-class objects;
one app can satisfy a broad range of users;
searching is better than pre-categorization;
browser features are useful for messaging;
a messaging app is a platform.

feeds are a transport format, not a feature

Feeds are currently presented in many application interfaces (including Firefox's) as a user-facing feature of the web. But feeds are data formats defining generic mechanisms for syndicating content. They're designed to be machine-readable, not human-consumable, and interfaces that expose them directly are often too technical, like the way websites publish both RSS and Atom feeds and Firefox asks users to pick between them (as aptly described by Atul Varma).

Treating feeds as a transport format means that rather than exposing them directly, Snowl should use them internally to give users a way to do the things they want to do, like find out when a website changes or keep up with what their friends are doing on the web.

So when a website provides RSS and Atom feeds of the same content, Snowl should pick a format instead of asking the user to do so. And when a website provides comment feeds, Snowl shouldn't expose those feeds to users, it should just show the conversations embodied in them to the users following that site.

The same is true for feeds provided by social network APIs. For example, the Last.fm API exposes the listening habits of its users' friends as individual feeds, but Snowl shouldn't make users manage individual feed subscriptions when they're really just interested in what their friends are listening to. Instead, it should present those individual feeds as Last.fm friend updates, separating them by friend--not feed--where appropriate.

people and conversations are first-class objects

There's no unique identifier for people on the internet. We each have an ever growing number of email addresses, usernames, and nicks on various websites, social networks, and messaging services. But we think of each person's various identifiers as representing the same being, and so should Snowl, so its users never have to figure out how they received a message (email, blog post, tweet, etc.) when looking for one from a particular person.

Also, context is crucial in conversations, and it's rarely obvious which message contains a particular portion of an extended conversation, so Snowl should let users interact with conversations rather than just their constituent messages, searching and browsing them as easily as they search and browse individual messages, and displaying messages in context.

one app can satisfy a broad range of users

Most users don't want to configure their experience, they just want things to work. And Snowl shouldn't force them to make unnecessary decisions. In fact, Snowl should need no preferences, because it always knows exactly what its users want.

Realistically, that's not possible, but the closer we can get, the better (while not trying to be too smart in ways that frustrate users). For example, a number of feed readers let users specify how often to update each feed. But this is information that it's possible to derive based on how often a feed is updated. There's no reason for Snowl to expose this question to users who shouldn't need to answer it.

Some users, however, do want to configure their experience. Others have unusual needs. And some have great ideas about how to create better experiences.

Firefox has shown that it's possible to build an application that satisfies all these users, and Snowl should follow in its pawsteps, using hidden preferences, subtle affordances, extensibility APIs, and other techniques to make it possible for those users to customize and modify Snowl to their hearts' content, while keeping the interface simple for everyone else.

searching is better than pre-categorization

Traditional messaging interfaces use pre-categorization to help you find messages. But the evolution of web search engines has shown that it's faster and simpler in many cases to simply search for what you want. Snowl should make it trivial to find any message quickly by searching for its content or metadata.

browser features are useful for messaging

Web browsers have developed a variety of features over the last dozenish years to make it easier for users to browse, find, save, and recall the web pages they visit. Snowl should take advantage of all these innovations to make accessing messages better, utilizing features like tabs for opening multiple messages, bookmarks to flag them for later reference, tagging for categorization, and the awesomebar for searching them.

a messaging app is a platform

Snowl was never intended to be just a feed and tweet reader. Feeds and Twitter are just two popular services with open APIs whose disparate kinds of messaging were good testbeds for early architectural and user experience decisions. Communication over the internet is evolving rapidly, and messaging apps have to evolve alongside it.

The best way to do that is to make Snowl a platform that others can extend to new messaging services and user experiences.

So Snowl comprises a datastore of subscriptions, messages, and people; a set of APIs for retrieving, storing, and sending messages; and a variety of interfaces for accessing them. And it should employ a flexible schema (like CouchDB's) to make it trivial to extend its data model; expose an API that makes it easy to add support for new messaging services; and provide useful primitives for building innovative new ways of looking at messages.

Snowl Futures

2009-01-07T23:59:00.000-08:00

With Snowl 0.2 almost out the door, I've been thinking about potential directions for its future development, and I've identified three possibilities.

Message Reader

The first is the idea that started the project: a message reader integrated into the browser, which uses Firefox features like tabs, bookmarks, history, the awesomebar, the sidebar, etc. to present messages.

Internet users live in their browsers, and much of their messaging is web-centric (feed items, tweets, messages sent via social networks, etc.). A message reader built into Firefox can aggregate those messages, store them locally (where their recipients have control over them), and provide a unified interface to them no matter where they come from and what protocols delivered them.

And it can help users uncover unknown sources of useful messages, like feeds from websites they frequent and updates from social networks to which they belong.

Snowl's biggest weakness relative to web-based alternatives (webmail, web feed readers, messaging apps built into social networks) is that it doesn't persist messages to a remote datastore, so users can't access them from anywhere. But it certainly could do so using Weave, CouchDB, or some other technology for synchronization to cloud storage.

Social Activity Tracker

The second potential direction for Snowl is for it to utilize feeds and social network APIs to keep users informed about what their friends are doing on the web. In other words, it could take up the mantle of The Coop, the idea for a Firefox-based social activity tracker that labs prototyped in 2007.

Just as with a message reader, a social activity tracker built into the browser would be in a unique position to expose useful updates to users across all of the sites they visit.

Snowl would need some modifications to behave in this way. In particular, it would need to get better at retrieving and aggregating lists of friends across multiple social networks. But its architecture is already well-suited to the task in a number of respects, since social activity is frequently exposed through messaging protocols, which Snowl has been designed to support.

Better Feed Reader for Thunderbird

The third potential is to integrate Snowl into Thunderbird as a better feed reader for that application.

Thunderbird's current feed reading feature is based on the Forumzilla feed reading extension I originally started working on in 1999/2000, and it suffers from a number of limitations and archaicisms. For example, it confines its messages to a separate "server" within the Thunderbird folder pane, and it provides only the traditional three-pane interface for reading them.

Snowl integrated into Thunderbird could break feed messages out of their "separate folder" ghetto, integrating them into the stream of messages from other sources, and provide a variety of useful views on them. And it would bring Twitter messaging to Thunderbird, too. Plus, Snowl developers would gain exposure to some of the interesting and innovative work happening in Thunderbird these days, which could benefit Snowl on Firefox.

The biggest challenge would be integrating Snowl into the very different capabilities provided by Thunderbird. Recent improvements to Thunderbird's extensibility and support for browser-like features such as tabs will make this easier, however.

I think all these directions have potential and are worth exploring. And while I'm going to remain focused primarily on Snowl as a message reader for now, I'll be conducting experiments along the way to learn more about the other possibilities. I'd also love to see other folks tackling them, so if you're interested in doing so, let's talk!

Snowl 0.2rc2

2009-01-07T23:47:00.001-08:00

The second release candidate of Snowl 0.2 is now available. This version fixes a few minor issues discovered in the first release candidate. Barring the discovery of additional issues that would block the release, this is the build that will be released as Snowl 0.2.

Give it a try, and let us know what you think.

Install Snowl

Snowl Central | Discussion Forum | IRC Channel | Bug Reports | Report a Bug | Source Code

Snowl 0.2rc1

2008-12-31T17:37:00.001-08:00

The first release candidate of Snowl 0.2 is now available. This version sports no new features relative to the last preview release, just a bunch of bug fixes. Barring the discovery of unexpected issues, this is the build that will be released as Snowl 0.2.

Notable bug fixes include:

an updated visual design with platform-specific icons for feeds and people;
Firefox is more responsive when Snowl is refreshing sources and building views;
multiple Twitter accounts no longer occasionally get confused for each other;
views update more consistently when messages and sources are added or removed;
the river and stream views always show messages in the order they were received.

As of this release, I've also switched to hosting Snowl development on the same infrastructure (source code repository, bug tracker, discussion forums, etc.) as other labs projects to make it easier for participants in those other projects to contribute to Snowl.

Give the release candidate a try, and let me know what you think.

Install Snowl

Discussion Forum | Bug Reports | Report a Bug | Source Code

simpler, easier string bundle API

2008-11-30T22:35:00.000-08:00

In the process of improving localizability in Snowl today, I put together a StringBundle JS module to make it easier to access string bundles from other JS modules (and JS XPCOM components and chrome JS, for that matter).

The module has a simple, easy-to-use API with a single get method that retrieves both plain and formatted strings:

let strings = new StringBundle("chrome://example/locale/strings.properties");
let foo = strings.get("foo");
let barFormatted = strings.get("bar", [arg1, arg2]);
for each (let string in strings.getAll())
  dump(string.key + " = " + string.value + "\n");

However, it also supports the API for the stringbundle XBL binding to make it easier to move from the binding to the module:

let strings = document.getElementById("myStringBundleElement");
              new StringBundle("chrome://example/locale/strings.properties");
let foo = strings.getString("foo");
let barFormatted = strings.getFormattedString("bar", [arg1, arg2]);
let enumerator = strings.strings;
while (enumerator.hasMoreElements()) {
  let string = enumerator.getNext().QueryInterface(Ci.nsIPropertyElement);
  dump(string.key + " = " + string.value + "\n");
}

The module is available with the other useful JS modules in the jsmodules project on mozdev.org. Documentation is embedded inside the module as well as on the project wiki.

Third (and Final) Preview of Snowl 0.2

2008-11-26T23:14:00.000-08:00

I've pushed a new preview release of the next version of Snowl. It includes an updated design for the "river of news" view with many improvements suggested by Alex Faaborg and others.

It also supports sending tweets in addition to receiving them via an interface built into the river and stream views. Just click on the "write a message" icon to expose it:

And it supports multiple Twitter accounts (thanks to Boris Zbarsky, who helped resolve a final vexing issue with HTTP auth), so if you happen to have more than one, you can keep track of all of them:

alta88 also contributed a bunch of improvements and bug fixes, including a context menu for sources with some common commands (like Refresh and Unsubscribe). And Atul Varma contributed a patch that will make it easier to plug in support for other sources of messages.

Finally, I fixed a big performance bug that was slowing down database queries for message content linearly with the database's growth in size. It looked something like this (courtesy beneneuman):

This preview is feature complete, which means no additional features will land in 0.2. From here on out, it's only important bug fixes, minor look and feel enhancements, localization support, and other low risk/polish/completeness issues until the release of 0.2.

So try it out, and let me know if you run into any of those kinds of problems (or any others, for that matter, as 0.3 development will be gearing up soon).

Install | Discuss | Chat | Bug Reports | Report a Bug | Source Code

Warning: this version is a primitive implementation with many bugs, and subsequent versions will include changes that break functionality and delete all your messages, making you start over from scratch.

making OS X stop prompting me for my wireless password

2008-11-19T12:02:00.000-08:00

I've long had problems automatically reconnecting to a certain WPA Enterprise wireless network from my MacBook Pro running Mac OS X 10.5.

Despite deleting the network from System Preferences > Network > AirPort > Advanced... > Preferred Networks, deleting its password from the login and System keychains using Applications > Utilities > Keychain Access, and then saving the network and credentials anew, the OS would prompt me to reenter my password for it every time I reconnected to it.

Some digging around on the web suggested that folks having a variety of Mac OS X wireless networking problems can sometimes solve them by deleting various configuration files, including /Library/Preferences/SystemConfiguration/com.apple.airport.preferences.plist.

I checked that file, and strangely, it listed a very old password for that wireless network. Turning off AirPort, deleting that file (I made a backup first just in case), and turning AirPort back on has resolved the problem. I can now reconnect to the network repeatedly (including after a reboot) without being prompted for my password.

news: links to Google Groups

2008-11-17T22:54:00.000-08:00

(Note: updated with a more reliable representation of the link.)
(Note: updated again to support news:<newsgroup-name> links.)

Here's an obscure hack.

Firefox 3 supports web protocol handlers (f.e. sending mailto: links to Gmail), while Google Groups archives Usenet. But as far as I can tell, Google Groups doesn't support news: links, even though Firefox can send them to it. It does, however, support retrieving messages by their IDs or newsgroup names, which news: links contain.

So how could we get Google Groups to load news: links passed to it by Firefox?

The solution is to pass them to an intermediary that extracts the IDs/names from the links and passes them to Google Groups. Here's a data: URL that does that:

data:text/html,\
  <html><body><script>\
    var url = '%s';\
    var stripPrefix = /^news:(\\/\\/[^\\/]+\\/)?/;\
    if (/@/.test(url))\
      window.location = 'http://groups.google.com/groups?selm='+url.replace(stripPrefix, '');\
    else\
      window.location = 'http://groups.google.com/group/'+url.replace(stripPrefix, '');\
  </script></body></html>

Unfortunately, it isn't easy to configure Firefox to use this URL as the news: protocol handler. Manually hacking mimeTypes.rdf is most unpleasant, while window.navigator.registerProtocolHandler only registers http(s): URLs.

But it's possible to construct a javascript: URL that does the same thing registerProtocolHandler does, namely call the handler service and register the handler with it directly.

The only trick is that you have to enter and run it in the Error Console, which has chrome privileges. Otherwise the URL won't have the privileges it needs to register the handler.

Here's a javascript: URL that registers the handler:

javascript: var Cc = Components.classes; var Ci = Components.interfaces; var handler = Cc['@mozilla.org/uriloader/web-handler-app;1'].createInstance(Ci.nsIWebHandlerApp); handler.name = 'Google Groups'; handler.uriTemplate = "data:text/html, <html><body><script> var url = '%s'; var stripPrefix = /^news:(\\/\\/[^\\/]+\\/)?/; if (/@/.test(url)) window.location = 'http://groups.google.com/groups?selm='+url.replace(stripPrefix, ''); else window.location = 'http://groups.google.com/group/'+url.replace(stripPrefix, ''); </script></body></html>"; var eps = Cc['@mozilla.org/uriloader/external-protocol-service;1'].getService(Ci.nsIExternalProtocolService); var handlerInfo = eps.getProtocolHandlerInfo('news'); handlerInfo.possibleApplicationHandlers.appendElement(handler, false); handlerInfo.alwaysAskBeforeHandling = true; var hs = Cc['@mozilla.org/uriloader/handler-service;1'].getService(Ci.nsIHandlerService); hs.store(handlerInfo); window.location = "data:text/html, <body> <p>The news: link handler for Google Groups has been installed. Try it with these links:</p> <ul> <li><a href='news:mozilla.support.firefox'>news:mozilla.support.firefox</a></li> <li><a href='news://news.mozilla.org/mozilla.support.firefox'>news://news.mozilla.org/mozilla.support.firefox</a></li> <li><a href='news:37604264.65F502CD@netscape.com'>news:37604264.65F502CD@netscape.com</a></li> <li><a href='news://news.mozilla.org/37604264.65F502CD@netscape.com'>news://news.mozilla.org/37604264.65F502CD@netscape.com</a></li> </ul> </body>";

To use it, copy the URL, open the Error Console (Tools > Error Console or Ctrl/Command+Shift+J), paste the URL into the evaluation field, and press the Evaluate button.

Once you've done that, try it out with these links:

When you click one, Firefox will ask you what you want to do with the link, and Google Groups should be an option on the list.

For the curious, here's a nicely formatted version of the code inside that javascript: URL, which is based on WCCR_addProtocolHandlerButtonCallback:

javascript:
var Cc = Components.classes;
var Ci = Components.interfaces;

var handler = Cc['@mozilla.org/uriloader/web-handler-app;1'].createInstance(Ci.nsIWebHandlerApp);
handler.name = 'Google Groups';
handler.uriTemplate = "data:text/html,\
  <html><body><script>\
    var url = '%s';\
    var stripPrefix = /^news:(\\/\\/[^\\/]+\\/)?/;\
    if (/@/.test(url))\
      window.location = 'http://groups.google.com/groups?selm='+url.replace(stripPrefix, '');\
    else\
      window.location = 'http://groups.google.com/group/'+url.replace(stripPrefix, '');\
  </script></body></html>";

var eps = Cc['@mozilla.org/uriloader/external-protocol-service;1'].getService(Ci.nsIExternalProtocolService);
var handlerInfo = eps.getProtocolHandlerInfo('news');
handlerInfo.possibleApplicationHandlers.appendElement(handler, false);
handlerInfo.alwaysAskBeforeHandling = true;

var hs = Cc['@mozilla.org/uriloader/handler-service;1'].getService(Ci.nsIHandlerService);
hs.store(handlerInfo);

window.location = "data:text/html,\
  <body>\
    <p>The news: link handler for Google Groups has been installed.\
       Try it with these links:</p>\
    <ul>\
      <li><a href='news:mozilla.support.firefox'>news:mozilla.support.firefox</a></li>\
      <li><a href='news://news.mozilla.org/mozilla.support.firefox'>news://news.mozilla.org/mozilla.support.firefox</a></li>\
      <li><a href='news:37604264.65F502CD@netscape.com'>news:37604264.65F502CD@netscape.com</a></li>\
      <li><a href='news://news.mozilla.org/37604264.65F502CD@netscape.com'>news://news.mozilla.org/37604264.65F502CD@netscape.com</a></li>\
    </ul>\
  </body>";

Of course Google Groups could make this hack moot by simply supporting news: links and protocol handler registration natively. For info on how to do that, Google Groups, see the news: URL standard in RFC 1738 and these subsequent IETF drafts, then read the Devmo docs on window.navigator.registerProtocolHandler.

Working at >Play

2008-11-17T12:05:00.001-08:00

Saturday I staffed the Mozilla Labs booth at the >play conference expo along with my colleagues Atul Varma (who also blogged about it) and Jay Patel. The event went really well, with a steady stream of visitors to our booth who were curious about Mozilla Labs projects and Mozilla in general.

Profit is not a Four Letter Word Here

I noticed early on that my standard spiel about Mozilla being nonprofit wasn't having the effect it normally has. Usually people nod approvingly when I explain that we are a mission-driven organization and community, but this time I was getting blank stares or even slight airs of disapproval.

I suppose that's because the conference was sponsored by a business school, and its attendees are mostly aspiring businesspeople, so nonprofit endeavors like ours don't have the same cachet they do amongst the web and open source hackers I usually meet at conferences.

The Pitches & Audience Reactions

Nevertheless, everyone was really friendly and positive about Firefox, and many of them had heard of at least some of the labs projects we were demoing (Weave, Ubiquity, Snowl, and the Concept Series, among others).

Everyone I asked also knew what open source was, and they were overall very positive about our plan to get more designers involved in open source development through the Concept Series.

And the booth duty was great for refining my descriptions of those projects. There's nothing like saying the same thing over and over again to separate the essence of the point from the redundant, misunderstood, or just plain unnecessary cruft. By the middle of the day, my pitches were crisp and tight.

Miscellaneous Firefox Feedback

One visitor told me he switched back to Safari because it lets him email a whole page (not just a link) with one click.

Another attendee asked for a lighter-weight variant of the master password feature that protects Show Passwords in the Saved Passwords dialog but doesn't prompt you to enter the master password each session, so you can protect your passwords from being retrieved by others without the annoyance of having to enter the master every time you restart your browser.

A third person asked for a way to see only unvisited search results when searching the web, so he can check occasionally to see if there's new information about a search term without having to scroll through all the stuff he's already seen.

And a professor suggested we could grow marketshare among students by pitching Firefox as the best browser for the popular iLearn online education software, as she solves many of her students' problems accessing her online classes by getting them to switch browsers.

egg timer for lightning talks

2008-11-13T09:52:00.001-08:00

Yesterday, for the Lightning Talks portion of the Mozilla Labs Meetup, I couldn't find a good online egg timer, so I created a simple one and put it up at eggtimer.org. Since then I've found lightningtimer.net, so I guess it wasn't necessary, but it's there now anyway.

2008-11-10T00:36:00.000-08:00


  <jstemplate>
    <description>Hello world!</description>
    <description>{"Hello world!"}</description>
    <description value="{'Hello world!'}"/>
  </jstemplate>


  <description>Hello world!</description>
  <description>Hello world!</description>
  <description value="Hello world!">


  <description>Good { new Date().getHours() > 11 ? "afternoon" : "morning" }.</description>


  <description>Good morning.</description>


  <?js for each (let i in [1, 2, 3]) { ?>
    <description>There's no place like home.</description>
  <?js } ?>


  <description>There's no place like home.</description>
  <description>There's no place like home.</description>
  <description>There's no place like home.</description>


  <script type="application/javascript">
    let people = [
      { name: "Jim",    rank: "celebrated", cerealBrand: "Special K" },
      { name: "Midge",  rank: "heard of",   cerealBrand: "Trix" },
      { name: "Genie",  rank: "unknown",    cerealBrand: "Muesli" },
    ];
  </script>

  <jstemplate>
    <table xmlns="http://www.w3.org/1999/xhtml">
      <tr>
        <th>Name</th>
        <th>Rank</th>
        <th>Cereal Brand</th>
      </tr>
      <?js for each (let person in people) { ?>
        <tr>
          <td>{person.name}</td>
          <td>{person.rank}</td>
          <td>{person.cerealBrand}</td>
        </tr>
      <?js } ?>
    </table>
  </jstemplate>


  <table xmlns="http://www.w3.org/1999/xhtml">
    <tr>
      <th>Name</th>
      <th>Rank</th>
      <th>Cereal Brand</th>
    </tr>
    <tr>
      <td>Jim</td>
      <td>celebrated</td>
      <td>Special K</td>
    </tr>
    <tr>
      <td>Midge</td>
      <td>heard of</td>
      <td>Trix</td>
    </tr>
    <tr>
      <td>Genie</td>
      <td>unknown</td>
      <td>Muesli</td>
    </tr>
  </table>

The code is available. Your thoughts & comparisons to JavaScript Templates, Better JavaScript Templates, JSmarty, seethrough and others are welcome!

Second Preview of Snowl 0.2

2008-10-20T12:33:00.001-07:00

I've just pushed the second preview release of the upcoming Snowl 0.2. It adds a non-columnar option to the river view along with grouping by time period to the river and stream views.

Here's the stream view grouped by day:

And here's the period selector in the river view:

The second preview release also includes a number of enhancements from alta88, who has added several layout and header options to the list view along with a bunch of other improvements (like a customizable toolbar button for quickly accessing Snowl features).

Here's the menu for selecting those layout and header options:

This preview release also includes many bug fixes to improve performance and functionality.

Still to come is a lot of behavior and visual design work, a number of additional bug fixes, and several more features, including Twitter-based message sending.

Get Snowl for Firefox

Get the preview release: Snowl for Firefox.

Warning: this version is a primitive implementation with many bugs, and subsequent versions will include changes that break functionality and delete all your messages, making you start over from scratch.

Get Involved

Let us know what you think by posting in the forum, reporting bugs, or conversing with us in the #labs channel on irc.mozilla.org. Or check out the source and submit your bug fixes and enhancements.

Easier Access to Sidebars

2008-10-07T13:13:00.000-07:00

Alex Faaborg suggested to me a few weeks ago that there should be an easier way to open and close Snowl's stream view sidebar, like a button that toggles it open and closed.

That got me thinking that the same is true for other sidebars, as the View > Sidebar menu seems like a relatively obscure and cumbersome way to access them. My inclination was to place a permanent interface on the left-hand side of the browser window, right where sidebars appear, that would be contextual, discoverable, and easily accessible.

Tabs seemed to fit these requirements and are consistent with Firefox's "one sidebar open at a time" behavior, so, with some helpful input from Dan Mills on how similar interfaces in other applications have behaved, I cooked up an experimental extension that implements a column of vertical tabs representing sidebars down the left-hand side of the browser window.

Dragging a tab to the right opens the corresponding sidebar, while dragging it back to the left closes it. Dragging also lets you set the sidebar width. Or open a sidebar to its previous width by simply clicking its tab (clicking again toggles it closed).

The extension supports both built-in sidebars (Bookmarks, History) and those provided by extensions, as long as the extensions use the standard machinery for defining their sidebars. And it extends that machinery with support for tab icons: just set the image attribute on your tag to the URL of the icon.

It uses the new -moz-transform CSS property to orient text vertically on the tabs (and a bit of the new drag-drop API to start the drag operation) so it only works on recent nightlies. And it's a prototype, so there's still some wonkiness in its appearance and behavior.

Check it out in the AMO sandbox, and let me know what you think. (Also note the All-in-One Sidebar, another take on the same concept.)

Stuck on Songbird

2008-10-03T19:15:00.001-07:00

I've tried the Mozilla-based open-source music player Songbird twice before, and each time I reluctantly retreated to iTunes for a variety of reasons: Songbird wouldn't play my DRM-encumbered iTunes Store tracks, it was cumbersome to use, it kept crashing or wouldn't start, etc.

But in August I stripped the DRM from my 50 encumbered songs by burning them to four CDs and then ripping them back. And then I heard that the latest version of Songbird (0.7) had a redesigned interface. So I decided to give it another try. And this time it stuck.

The major reason is the interface redesign, which has simplified the application considerably, making it much easier to navigate. But it also doesn't crash much anymore and has started up fine every time.

I've been using Songbird almost exclusively for the last few weeks, except when I need to burn a CD (which it still doesn't do) and during the occasional foray into the iTunes Store to see if it has DRM-free versions of songs I can't find in the Amazon MP3 Store, like Ministry's original recording of Jesus Built My Hotrod or The Damned's remake of Jet Boy, Jet Girl (sadly, it usually doesn't).

I even activated its scrobbler support, and it's been pushing my listening habits to my public last.fm profile, which feels uncomfortably revealing, although no more so than having dozens of my colleagues following my decidedly non-work-related tweets.

And I've tried out its Songkick functionality for automatically finding concert dates for the artists in my library, which feels like a killer feature, since it's so much easier than searching for concerts manually (or tediously programming Ticketmaster/Live Nation to keep me in the loop).

Finally, I've sampled its SHOUTcast internet radio integration, which seems like it could be a great way to get someone else to mix my daily soundtrack for me, except that I haven't yet put in the effort to find the stations I want to listen to from the overwhelmingly voluminous selection of them.

Overall, I'm pretty happy with Songbird. Support for burning CDs and better integration with the Amazon MP3 Store are the only major features I'm missing. The rest is just nits.

(Note: recent versions of Songbird supposedly play DRM-encumbered iTunes Store tracks just fine, although I'm glad to be DRM-free anyway and plan to remain so from now on by not purchasing any more encumbered music.)

sharing one Mozilla source tree with Linux/WinXP VMs on Mac host OS

2008-09-26T14:48:00.000-07:00

Here's how I shared one Mozilla source tree on my Mac OS X host OS (one Core 2 Duo, 4GB physical RAM) with two VMware Fusion VMs, one running Ubuntu Linux 8.04 (two CPUs, 1GB RAM), the other running Windows XP (one CPU, 512MB RAM):

I checked out the source tree to ~/Mozilla/source on my Mac's filesystem.

I configured each VM with one shared folder via Fusion's Virtual Machine > Shared Folders > Shared Folder Settings... configuration dialog. In both cases, I shared my Mac user account's home folder (/Users/myk). Fusion 2 named both shares myk (Fusion 1 had named the Windows share myk On My Mac).

I made these shares read/write so I could manipulate the tree from the VMs (particularly from the Linux one, where I do most of my development) and also because the Mozilla build process tries to modify the source tree, even when you're using an objdir (f.e. bug 384978), and the build process runs smoother if you let it.

On Linux, the shared folder showed up at /mnt/hgfs/myk. Because of a limitation in Fusion (described in the release notes as "Shared Folders permissions might be too restrictive in Linux and Mac OS X Server guests"), I had to configure the /etc/fstab entry for the shared folder to mount with my Linux user account's uid/gid:

# Beginning of the block added by the VMware software
.host:/   /mnt/hgfs   vmhgfs   defaults,ttl=5,uid=myk,gid=myk   0 0
# End of the block added by the VMware software

Note: this modification gets reset and has to be redone every time I reinstall VMWare Tools (i.e. after each kernel upgrade).

On Windows, the shared folder showed up at Start > My Network Places > Shared Folders on .host. Fusion 2 automatically created a network drive for the shared folder, mapping it to the uppercase drive letter Z:. When I was using Fusion 1, I manually created the network drive via Tools > Map Network Drive in Windows Explorer.

In older build environments, I then had to create /etc/fstab (following the instructions in /etc/fstab.sample) to mount the network drive, but I think simply mapping the drive automagically makes it available at its lowercase Unixy equivalent (f.e. /z) in the latest versions of MozillaBuild (perhaps after a MozillaBuild or Windows restart?).

I only share my source tree, putting config files in ~/Mozilla/configs and builds in ~/Mozilla/builds on the Mac and Linux filesystems and in /home/myk/Mozilla/(configs|builds) on the Windows filesystem (as my home directory on Windows is /c/Documents and Settings/myk, and Mozilla has trouble building to a directory with spaces in its path).

Once configured as described, building on each OS became the simple matter of crafting the build config file, changing to the source directory, and calling make, for example on Linux (with this config file):

cd /mnt/hgfs/myk/Mozilla/source
time MOZCONFIG=~/Mozilla/configs/minefield-opt make -f client.mk build

On Mac (with this config file):

cd ~/Mozilla/source
time MOZCONFIG=~/Mozilla/configs/minefield-opt make -f client.mk build

And on Windows (with this config file):

cd /z/myk/Mozilla/source
time MOZCONFIG=/home/myk/Mozilla/configs/minefield-opt make -f client.mk build

Note: compiling on Linux seems pretty speedy, but compiling on Windows is dog slow, perhaps even slower in Fusion 2 than in 1. I haven't tried it lately, but it might be faster to share the tree with Windows using SMB.

Note: it's theoretically possible to compile on two or all three OSes simultaneously, but it does slow down the machine, and I got build failures the few times I tried it (I don't remember exactly what now, I think something about the Windows build process being unable to access certain files).

Rocking the Linux User Experience (Boat)

2008-09-19T06:40:00.000-07:00

Mark Shuttleworth has recently announced plans to rock the Linux user experience (yes, I know I'm a week late; I've been on vacation and am just now catching up).

I've been an avid Linux user for about a dozen years, first on Red Hat, then Fedora, and lately Ubuntu, and I've had my share of frustrations with the OS, so I'm thrilled to hear about this initiative.

And I have a piece of advice: don't be afraid to cross (and dissolve) boundaries between layers of functionality and give developers the authority to fix problems no matter where they reside, even at the risk of ruffling feathers (as did ZFS with its "damn the software stack, full speed ahead to the desired outcome" approach).

I say this because my small window into the GNOME development process (bugs 482354 and 162726) suggests its developers spend way too much time trying to figure out which of the many layers of functionality in the Linux desktop is responsible for an issue (and thus who is responsible for fixing it).

Mozilla isn't perfect in this regard either, but when it works well, it's because developers take responsibility for making the user experience great no matter what part of the code needs to be touched (like the recent progress being made in bug 248970 by Ehsan Akhgari in collaboration with others on a private browsing mode for Firefox).

If you want to rock the Linux user experience, be willing to rock its boat as well.

Alt/Cmd+Left/RightArrow brainsprinkling

2008-09-02T08:26:00.000-07:00

Recently some folks have been blogging about Ctrl+Tab. It's great to see that shortcut getting love, and it reminds me that there's another one for navigating between pages that could use similar attention: Alt/Cmd+Left/RightArrow for going backwards and forwards through history within a tab.

Like the old Ctrl+Tab implementation, Alt/Cmd+Left/RightArrow only lets you move one page at a time, and you can't see where you're going until you get there. And sometimes you land on a page that is the product of a POST request, which you don't know until you are forced by a modal dialog to decide whether or not to resubmit data that you don't get to see when making the decision.

We could enable multi-page moves by making the shortcuts work similarly to Alt+Tab in operating systems: holding down the Alt key and pressing a horizontal arrow key would bring up a list of icons representing the pages in the history (perhaps formatted like Alt+Tab in operating systems or via the 3D effect Jono suggested for Ctrl+Tab).

Each icon would be a screenshot of the page as it was when you left it, and the adjacent page to the current page would be selected by default. But as long as you held down the Alt key, the list of pages would stay on the screen, and pressing the arrow keys would let you travel back and forth through it. Once you let go of the Alt key, Firefox would switch to the page that was selected at the time.

This behavior might also reduce frustrating clicks on posted pages, although the better solution, as Dan Mills recently pointed out in a conversation, would be to stop forcing users to reload pages just to go back (or forward) to them, even if they were the result of a POST.

But if we can't do that for some important technical reason, we could at least display a non-interactive and suitably-dressed snapshot of the page and drop down a non-modal notification bar at the top of the tab explaining why we can't provide the page itself and allowing the user to see what they are potentially going to reload.

And the list of pages could itself indicate which of its pages are POSTed, thus providing the user two levels of useful indication of what will happen when they try to go back to that page.

Of course, there's more to history than the past and future of each individual tab, and pan-tabscape history navigation affordances would also be useful to think through. But there's still a place for a tab-specific interface, given that many such trails represent a specific path through the web with relevance and meaning to the user, so it'd be good to improve the way Alt/Cmd+Left/RightArrow works (or invent even better tab history traversal).

Thoughts?

2008-09-02T00:12:00.001-07:00

A couple weeks ago I blogged about my priorities for the next version of Snowl. I've just uploaded a preview release of the next version to addons.mozilla.org with an initial implementation of a view optimized for short messages and recent updates:

The view is implemented as a sidebar that shows short messages (such as from Twitter) in their entirety and displays the subjects of long messages with links to their content. Messages are sorted in the order received, with the most recent ones on top, to make it easy to see the newest stuff at a glance.

Plans

There's still plenty of functionality yet to be implemented in the sidebar, including:

grouping messages by time period (this morning, yesterday, last week, etc.);
making it possible to see some of the content of long messages;
an easier way to open and close the sidebar (f.e. a button that toggles it on and off).

I also want to improve elements of the visual design. In particular, I'd like to add a subtle but noticeable visual cue that messages have arrived (f.e. making messages slide into place from the top of the sidebar).

And I'm still working on implementing message sending and conversations as first-class objects for version 0.2. This preview release is just a taste of the first of several upcoming features.

Other Changes

This release also fixes a number of bugs and makes some improvements to the architecture (there seems to be a neverending supply of such infrastructure work, but it's all necessary to prototype features on top of). And it improves access to Snowl's features via some conventional extension integration points: an item in the Tools menu, an icon on the statusbar.

Get Snowl for Firefox

Get the initial prototype: Snowl for Firefox.

Warning: the initial prototype is a primitive implementation with many bugs, and subsequent versions will include changes that break functionality and delete all your messages, making you start over from scratch.

Get Involved

Let us know what you think by posting in the forum, reporting bugs, or conversing with us in the #labs channel on irc.mozilla.org. Or check out the source and submit your bug fixes and enhancements.

Content Preferences, Now With Toolbar Widgets

2008-08-24T20:01:00.000-07:00

Last weekend I updated my Content Preferences extension to work with Firefox 3.

Along the way, I finished up an additional feature for it: pref widgets you can add to your browser toolbars. The widgets let you set page zoom, page style, and character encoding directly from visible browser chrome, and you use them by customizing your toolbars to include them via the View > Toolbars > Customize command.

Here's the page style widget in the menubar on Linux:

Here are all three widgets on their own toolbar on Mac:

As with page zoom in Firefox 3, these widgets are site-specific and persist across browsing sessions. And as with earlier versions of the extension, they're also available in a sidebar that follows you as you browse around the web and also lets you set global defaults:

UI like this has three possible futures:

If it's useful to a broad range of users a significant percentage of the time, it belongs in the default chrome.

The page zoom widget is a candidate for this placement. Among other indications, a number of popular sites, like CBS News, provide a version of it to their users within the default "chrome" of their content pages:

Otherwise, if it's useful enough to enough users (a fuzzy definition, to be sure), it belongs in optional chrome, either via an extension or in well-concealed parts of the core product (hidden preferences, the browser toolbar palette, etc.).

The character encoding widget perhaps satisfies these conditions, as it might be very useful in certain parts of the world where automatic charset specification and detection is not yet up to snuff.

Otherwise, it doesn't belong in the chrome at all.

I wonder if that's the case for the page style widget, since browser UI for website skinning has never caught on.

But there's a chicken and egg problem here, since sites don't have impetus to provide multiple skins without useful browser UI for applying them, while browsers don't feel pressure to implement good UI when so few sites take advantage of it. Maybe a persistent site-specific page style widget is just the ticket to change that.

I'm not happy with the widgets, though. The page style and charset widgets simply mirror the functional but archaic menu-based UI in the View menu, and while the page zoom widget tries something new, and it's easy enough to understand, it's difficult and frustrating to use, since it requires precise manual dexterity to set a specific zoom level.

It could be improved in a variety of ways--indicators of which direction does what, markers and snap anchors at specific zoom levels, etc. But maybe there's something even better. Two big buttons for zooming in and out?

A set of sticky buttons that each represent a zoom level?

As for page style, perhaps it could display a set of screenshots showing the appearance of the page with each alternative style applied. And the charset widget could show you what the text would look like if you applied each encoding.

Thoughts?

Snowl Feedback and Futures

2008-08-13T15:16:00.001-07:00

Last month I blogged about Snowl, an experiment with messaging in the browser. Two weeks ago I presented it at the Firefox+ Summit. And last Wednesday I released an initial prototype.

I've been getting tons of feedback since then from a variety of sources, including discussion at the summit, comments on the announcement, AMO reviews, discussion in the forum, news and commentary (TechCrunch, ReadWriteWeb, ZDNet, Computerworld, Ars Technica, Slashdot, Digg, etc.), blog posts, and bug reports.

Some opinions I've seen expressed more than once:

the river view feels like it fits into Firefox
the list view doesn't mix well with general web browsing
"I'd rather use a standalone application."
"I'd like even more integration with Firefox."
many of the prototype's features should be part of Thunderbird
it lacks a number of useful features (f.e. sharing)
it contains a number of bugs
it has lots of potential

Overall, there's a lot of interest in Snowl, in browser/messaging integration, and in messaging innovation generally. There's plenty more to explore here, and I'd like to see Snowl experiment with the following features in particular:

simple web search engine-like attribute-based search
a message view optimized for short, simple messages (Twitter, IM, SMS)
an experimental message view that uses color, size, graphics, word clouds, animation, or other techniques to help users make sense of their flood of messages
support for sending messages, including responding to tweets and posting comments to blogs
easy access to feeds from frecent (frequent+recent) sites, sites you are currently browsing, live bookmarks, and feed items you've commented on
conversations (i.e. threads) as first-class objects
better support for people as first-class objects
email, IM, and other message sources
user-initiated and automated message grouping (Home/Work, Important/Unimportant, Today/Yesterday/Last Week, etc.)

Of those, I'll be focusing on a short message view, message sending, and conversations as first-class objects for the next iteration.

If you have a burning desire to see something else on this list (or something else entirely) happen sooner than later, your contributions are welcome! Discuss ideas and post mockups to the discussion forum, pick up the source code from the code repository, and submit patches in bug reports.

Thunderbird 2.0.0.16 with tabs

2008-07-24T16:59:00.001-07:00

Last week I got a new MacBook Pro to replace my (two year) old one. Among the problems with the old machine was a perennial lack of space on the hard drive. I kept having to compress, archive, and throw away files to keep myself (barely) in the black.

The new machine's drive is twice as big, and that means plenty of space to build updated packages of Thunderbird 2 with my tabs patch based on the just-released Thunderbird 2.0.0.16. The packages are available for Mac OS X, Linux, and Windows.

If you are the adventurous type, however, check out the Thunderbird team's 3.0 alpha releases, which have tabs built-in by default. And note the discussion on an experimental message view that aims to come up with an even better approach to opening multiple messages.

Incidentally, I'm standing on the shoulders of giants here. The only reason I can build these at all is because Mozilla's build/release team puts hard work into maintaining a build system and toolchain that makes it relatively easy to compile this several-year-old codebase even on new hardware running recent versions of all three operating systems. Kudos and many thanks to them.

Snowl: an experiment with messaging in the browser

2008-07-14T17:29:00.000-07:00

Last August, after Mitchell blogged about the future of email and penned an email call to action, I posted some thoughts about what a next-generation conversations app might look like. I've kept thinking about it since then, and several months ago I proposed a labs experiment to build a Firefox extension that tries out some of those ideas.

Lots of users use desktop applications like Thunderbird and Apple Mail to converse with each other online, while many others use web apps, including not only webmail but also social networks, web discussion forums, and other site/service-specific tools. Is there a role for Firefox in this mix?

That's the key question I'm trying to answer.

I've been hacking on a prototype on and off since then. It's not quite usable yet, but it's getting there. It currently has basic support for subscribing to, searching, and browsing messages from feeds via two views: a list view similar to a three-pane email application's interface and a variant of the "river of news" view described by Dave Winer.

I plan to have a 0.1 version of the prototype ready by the Mozilla Summit in two weeks, where I've proposed a session to present and discuss the experiment. In the meantime, adventurous readers are welcome to check out the source and send me feedback via comments on this blog post, email, IRC, Facebook, your own blog post that references this one, etcetera, etcetera, and so forth.

Why I Host Projects on Mozdev

2008-07-07T23:59:00.001-07:00

I've been using Mozdev for almost eight years, ever since it started hosting Forumzilla, my project to build a Mozilla-based web forum reader (which eventually became a Thunderbird extension and then Thunderbird's built-in feed reading feature).

Mozdev plays the critical role in the Mozilla community of hosting Mozilla-related projects that aren't considered core enough to the Mozilla mission to host on official community infrastructure. It's a great adjunct to AMO, which distributes many of the projects that Mozdev hosts.

Over the years, I've been happy to host a number of such projects there, including the aforementioned Forumzilla plus Bugxula (defunct), Tinderstatus, and revision control/bug tracking for the Labs project Personas.

Although there have always been alternatives, they have been unpalatable: SourceForge has a cumbersome and unfamiliar interface, and hosting on my own server would have meant doing all my own systems administration. I use Mozdev because I want to focus on my projects, not on the infrastructure for developing them.

Over the last couple of years, Google Code has become an option. Although it provides much less functionality than Mozdev (and limits how many projects you can create), it does have a simpler interface and a more modern revision control system.

The folks who run Mozdev (which includes me) want simplicity and modern services (without sacrificing power) for Mozdev too, and we've identified three priorities in that regard: adding Mercurial for revision control, implementing WYSIWYG content editing, and automating project creation and management.

So I'm thrilled to read Mozdev developer Doug Warner's announcement today, via a post to the project owners mailing list, that he has landed Mercurial support. Now you can get all the goodness of Hg hosted on your behalf for any of your Mozilla-related projects.

Eight years later, I think Mozdev remains the best place to host my projects, and it's just getting better. I can't wait to see what's next (and I have some ideas about what simple WYSIWYG editing could look like, about which more soon).

Merging with Mercurial and Meld

2008-06-03T18:19:00.000-07:00

[Update: see Merging with Mercurial 1.0 and Meld for more up-to-date info on the experience with Mercurial 1.0, which comes with Ubuntu 8.10.]

When confronted with a merge conflict, Mercurial 0.9.5 (the version that comes with Ubuntu 8.04) uses its hgmerge script to call meld in a way that displays your version of the file on the left, the other version on the right, and hg's attempt to merge them in the middle, with conflict markers where it was unable to do so.

Here's meld handling the Merging conflicting changes example from the hg book:

You're supposed to fix the one in the middle, resolving the conflicts between the ones on either side, and then save the middle one (which will get saved to your working directory, from where you can commit your merge).

The following patch hacks hgmerge to display the base version (the one from which your version and the other version originated) on the left, the other version on the right, and your version in the middle.

--- hgmerge.orig        2008-06-01 13:51:10.000000000 -0700
+++ hgmerge     2008-06-01 14:35:46.000000000 -0700
@@ -158,13 +158,12 @@
        conflicts_or_success
    fi

    if [ -n "$MELD" ]; then
+        cp "$BACKUP" "$LOCAL"
        cp "$BACKUP" "$CHGTEST"
        # protect our feet - meld allows us to save to the left file
-        cp "$BACKUP" "$LOCAL.tmp.$RAND"
-        # Meld doesn't have automatic merging, so to reduce intervention
-        # use the file with conflicts
+        cp "$BASE" "$LOCAL.tmp.$RAND"
        $MELD "$LOCAL.tmp.$RAND" "$LOCAL" "$OTHER" || failure
        # Also it doesn't return good error code
        $TEST "$LOCAL" -nt "$CHGTEST" && conflicts_or_success || ask_if_merged
    fi

Here again you're supposed to fix and save the file in the middle, which gets saved to your working directory.

Here's what the example looks like using the hacked version of hgmerge:

After trying both versions of the script on several test and real merges (a few of which I screwed up), it's still not clear to me which approach is better (or if there's something better still). David Baron pointed out in a conversation that it can be useful to see the base version, but it's also useful to distinguish between your version and the version that ultimately results from the merge (which is presumably why kdiff3, which is shown in the book, displays all four: base, yours, other, and final).

Thoughts?

(Note: Devmo's Mercurial basics says to use Mercurial version 1.0 or later, although I hear that doesn't even include hgmerge, leaving configuration of a merge tool entirely up to each user, so the question is even more significant there.)

JS 1.8 syntax checking in Komodo

2008-06-03T16:42:00.000-07:00

I've been using JavaScript 1.8 expression closures lately, but ActiveState Komodo's JS syntax checker, which is just SpiderMonkey 1.7, doesn't recognize them, so it treats them as a syntax error and stops checking the file:

Fortunately, the fix turns out to be pretty simple. Komodo ships with SpiderMonkey 1.7 as an executable, so I first built SpiderMonkey 1.8 (on Linux) using the SpiderMonkey build instructions:

cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -l mozilla/js/src mozilla/js/src/config mozilla/js/src/editline mozilla/js/src/fdlibm
cd mozilla/js/src
BUILD_OPT=1 make -f Makefile.ref

Then I backed up Komodo's version and replaced it with the one I built:

cp Linux_All_OPT.OBJ/js ~/Applications/Komodo-IDE-4/lib/mozilla/js18
cd ~/Applications/Komodo-IDE-4/lib/mozilla
mv js js17
ln -s js18 js

Voila! Syntax checking works for expression closures:

In theory I might have just horked some part of Komodo that depends on JS 1.7, although the New in JavaScript 1.8 doc doesn't mention breaking changes between the two versions, and so far Komodo seems to be working fine.

If it does create problems, however, then a more contained fix, as ActiveState's Todd Whiteman points out on the Komodo Discuss mailing list, would be to update koXPCShellLinter.py's jsInterp variable to point to the 1.8 executable.

XPCOMless Preferences API

2008-05-11T23:41:00.000-07:00

I've been working on yet another JavaScript API for accessing preferences. My goals for it are simplicity, intuitiveness, power, and perhaps performance. I'm also interested in learning whether freeing it from the restrictions of XPCOM can make it better than existing APIs.

The Basics

It's a JavaScript module, so you start by importing it from somewhere:

Components.utils.import("resource://somewhere/Preferences.js");

Getting and setting prefs is easy:

let foo = Preferences.get("extensions.test.foo");
Preferences.set("extensions.test.foo", foo);

As with FUEL's preferences API, datatypes are auto-detected, and you can pass a default value that the API will return if the pref doesn't have a value:

let foo = Preferences.get("extensions.test.nonexistent", "default value");
// foo == "default value"

Unlike FUEL, which returns null in the same situation, the module doesn't return a value when you get a nonexistent pref without specifying a default value:

let foo = Preferences.get("extensions.test.nonexistent");
// typeof foo == "undefined"

(Although the preferences service doesn't currently store null values, other interfaces like nsIVariant and nsIContentPrefService and embedded storage engines like SQLite distinguish between the null value and "doesn't have a value," as does JavaScript, so it seems more consistent and robust to do so here as well.)

Look Ma, No XPCOM

Because we aren't using XPCOM, we can include some interesting API features. First, as you may have noticed already, the interface doesn't require you to create a branch just to get a pref, but you can create one if you want to via an intuitive syntax:

let testBranch = new Preferences("extensions.test.");
// Preferences.get("extensions.test.foo") == testBranch.get("foo")

The get method uses polymorphism to enable you to retrieve multiple values in a single call, and, with JS 1.7's destructuring assignment, you can assign those values to individual variables:

let [foo, bar, baz] = testBranch.get(["foo", "bar", "baz"]);

And set lets you update multiple prefs in one call (although they still get updated individually on the backend, so each change results in a separate notification):

testBranch.set({ foo: 1, bar: "awesome", baz: true });

Performance?

Getting prefs via the module is several times slower than getting them directly from the preferences service, but it's much faster than using FUEL, and we can make the module just as fast as the direct approach by making it cache values (at some unknown set and memory cost):

Nevertheless I wonder if it's worth the added complexity and other iatrogenic costs of caching, given that preferences generally don't get accessed very frequently, and all of these methods are fast enough for small numbers of accesses.

Everything Else

I haven't yet built the rest of the API (has, reset/clear, locking, adding and removing observers, etc.). Is it worth doing so? Is this API better enough than FUEL's or simply direct access to the XPCOM preferences service? And are there other improvements we can make given that we aren't limited to the language features XPCOM supports?

(To try it out, download the Preferences and/or CachingPreferences modules.)

Update: the latest version of the module is available at http://hg.mozdev.org/jsmodules/file/tip/Preferences.js. That link will stay up-to-date with changes to the module.

a trademark to distinguish network neutral providers

2008-04-28T17:30:00.000-07:00

While on vacation last week, I saw a sign in front of a Burger King in New York advertising free wifi. The sign listed six things you can do with it (downloading songs, chatting, etc.), which left me wondering whether they provide the whole whopping internet or just the selected portions they highlight.

And that got me wondering whether it would make sense to trademark a logo and phrase for distinguishing internet providers that provide unobstructed access to make it easier for users to pick network neutral wifi hotspots at restaurants and hotels, DSL/cable providers, and mobile plans.

Providers licensing the logo could still rate limit, as long as they didn't do so on the basis of site or protocol. And the trademarked content would be designed to be simple and understandable by non-technical users, like Creative Commons' license logos, TRUSTe's privacy seals, and the feed icon.

I'm not sure what organization would be most suitable for running such a program, but it should be not-for-profit, as Creative Commons, TRUSTe, and Mozilla all are.

Properly implemented, it seems like a program like this would make it a whole lot easier for users to pick providers that don't have frustrating problems caused by access obstructions while putting pressure on providers to provide the whole internet so they can qualify for the program.

Thoughts?

me three

2008-04-14T15:03:00.000-07:00

myk@myk:~$ uname -a
Linux myk 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux
myk@myk:~$ history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
115 cvs
61 cd
50 ls
33 safari
31 komodo
28 firefox
23 cp
16 ll
12 zip
12 scp
11 mv

proposed changes to Mozdev roadmap

2008-04-02T09:44:00.000-07:00

I'm on the board of the Mozdev organization, and we're in the process of reviewing our roadmap for development.

We're a small organization with limited resources, so we can't do everything that would be useful, and it makes sense to leverage the tooling taking place elsewhere in the Mozilla community.

At the same time, I want Mozdev to blaze a trail on the usability and functionality of key services like website development/deployment tools and discussion forums. And it should be super-easy to set up and manage a project on Mozdev.

So I am proposing that we revise the roadmap to make the following three items the top priorities for the organization:

Add one additional revision control system, and deprecate CVS.

The two systems in the running are Subversion and Mercurial, and they each have their advantages. Subversion's chief advantages are its similarity to CVS and familiarity to some existing project owners, while Mercurial's are its modern design (including support for distributed development) and its momentum in the Mozilla community.

Overall, I think we're better off adding Mercurial, which has the full weight of Mozilla tooling efforts behind it and which is on track to become the most popular system in the Mozilla community (until the next one comes along, anyway).

So I think we should add Mercurial to the site. But this would not preclude adding Subversion as well at some point if resources became available to deploy and maintain it.
Implement a new website hosting service with simple WYSIWYG wiki publishing and scp/sftp/ftps file upload.

Here we're tackling two constituencies at once: those who just want a simple hosting option where it is easy to create and edit pages, and those who want complete control over the files that make up their site.

The file upload option also addresses the needs of users who generally want the simple approach but occasionally need to upload a file or two (f.e. an image to display on a page in the wiki or a presentation in PDF format).
Automate project creation and management so that project creation requests can be addressed in minutes or hours and users can self-manage their projects.

This item combines the automate project creation process and centralized account management system items from the second and third priority groups, respectively, on the existing roadmap.

I think we should continue to require approval of new project requests from unknown people but no longer require approval of those from known, trusted people like existing project owners, so that trusted people can have a new project up and running in seconds.

There are certainly many other changes that would be beneficial, like integrating forums, feeds, mailing lists, and newsgroups, so users can pick their preferred delivery format and get the same communications as on every other channel.

But these three changes would make a big difference in the usability and functionality of the site, and I think we should make them our top priorities.

Thoughts?

Dynamic Personas - How They Work

2008-04-01T14:15:00.000-07:00

The recently released update to the Personas extension includes support for dynamic personas, which are personas that change over time. Here's a technical overview of the history and present condition of the feature (for a non-technical overview, see the labs blog).

Take One

Original discussions for making personas more dynamic started with the idea of building an API for them to specify a series of background images and when to switch between them. But the more ideas we had about what personas might want to do, the more complicated this API became.

I wanted something both simpler to scale to more complex functionality and more powerful right off the bat, so I suggested we simply stick iframes behind the browser chrome at the top and bottom of the browser window, let personas load any web content (HTML, SVG, etc.) into them, and let them update themselves as needed ajaxically.

That seemed promising, so I prototyped it by XBL binding the top and bottom chrome into XUL stacks, making their backgrounds transparent, and sticking iframes underneath them.

That worked great until I locked down the iframes with type="content" for security, at which point they were hoisted to the tops of the stacks and covered up the browser chrome.

I asked about this on IRC, and roc pointed me to bug 130078, which won't be fixed in Gecko 1.9. So I had to find a different solution.

Take Two

The one I hit upon, which is in the latest release, preserves as much of the web content magic of the original solution while still working (safely). And it still enables personas to change over time, albeit not as rapidly.

The extension creates two iframes in the hidden window, loads the persona content into them (which can still be any web content), takes a snapshot of them using the canvas 2D context's drawWindow method, converts the snapshots to data: URL-encapsulated PNG images using canvas's toDataURL method, and then makes those images the background images for the top and bottom chrome.

Rinse and Repeat

The extension then leaves the persona loaded in the iframes and periodically (once per minute by default) updates the browser chrome with new snapshots. And occasionally (once per hour by default) it reloads the persona from scratch, although personas are of course free to update themselves more frequently.

Once per minute is obviously not fast enough for animation (like an aquarium with fish swimming around in your toolbar), but it's fast enough for gradual changes, like a panoramic landscape that darkens as the sun sets or a pictorial depiction of the weather report. And there are plenty of interesting personas for which this update frequency is fast enough.

(Incidentally, one can jack up the frequency with a hidden preference, but doing so is not recommended, since it could impact performance).

Bits and Pieces

When dynamic personas change the background, the optimal foreground color might change too, so the extension sets the foreground (text) color to the one specified on the root element of an HTML dynamic persona.

For example, Heldenhaft's Paderborn, Germany panorama persona is dark at night and light in the daytime, so I adapted some code from an NOAA Sunrise/Sunset Calculator to enable it to determine the status of the sun at its location and set its foreground color appropriately.

And if you want to test out this "any web content" claim, just select Preferences... from the personas menu, press the Custom Persona Editor... button to open the custom persona editor, and enter any URL (f.e. http://www.mozilla.com/) into the Header or Footer fields. It might not be pretty, but it'll show you a chunk of the page behind the chrome.

Locking it Down

The code is a actually bit more complicated than described above, because the hidden window is an HTML document on Windows and Linux, and HTML iframes can't be locked down with type="content".

So instead of creating those iframes in the hidden window, it creates another iframe in the hidden window that loads a XUL document that contains the two iframes that load the persona content.

Tests like this one (and a version that tests the personas code directly) demonstrate that the content iframes are indeed locked down, so while personas can do anything web content can do in a browser tab, they can't break out of the content jail and access chrome UI or capabilities.

The only thing injected into chrome is static PNG snapshots of web content.

Of course, if you can think of a way around that or another security issue, I and other Personas hackers would be very interested in your thoughts. To confirm your suspicions, install and test the extension or peruse the code online.

a trio of extensions

2008-03-24T17:30:00.000-07:00

Last week while on vacation I spent a bit of time hacking, and I cooked up three extensions to improve the Firefox experience.

The first two are pretty trivial:

Bookmark Toolbar Icons unhides those icons on the Mac using Vlad's user chrome code (with the enhancement Abdulkadir Topal suggested in his comment on Vlad's post):

Extensions are easier to install and remove than chunks of user chrome code, so this makes that enhancement accessible to greater numbers of users.

And Command-PageUp/PageDown lets you use those shortcuts for switching between tabs on the Mac, which is handy for selectively closing tabs via the keyboard, since otherwise you have to switch accelerators between moving to a tab (Ctrl-PageUp/PageDown) and closing it (Cmd-W).

Besides making that use case easier, the Command accelerator feels a bit more Mactuitive in general, although there's no standard shortcut for tab-switching in particular. Apple apps like Safari and Terminal use the clunky Cmd-Shift-[/], while Colloquy uses Cmd-LeftArrow/RightArrow, and ActiveState Komodo uses Cmd-PageUp/PageDown (i.e. the same shortcut this extension enables in Firefox).

The third extension, Bookmarks UI Consolidator, is more involved. It consolidates the Bookmarks menu in the menubar and the Smart Bookmarks folder in the Bookmarks Toolbar into a single Bookmarks folder in the toolbar:

Besides simplifying the UI, the extension makes the toolbar keyboard-accessible. Just press Alt-B (Ctrl-B on Mac) to focus and open the folder, Esc to close it again (but leave it focused), and then the LeftArrow/RightArrow keys (or Tab/Shift-Tab) to move between items on the toolbar. Space/Return/Enter on an item in the toolbar loads a focused bookmark and opens a focused folder.

(That second step in the process, hitting Esc, shouldn't be necessary, but I haven't yet figured out how to make the toolbar behave like the menubar, where hitting RightArrow while a menu is open focuses the next menu to the right if the current menuitem doesn't have a submenu.)

Note: focusing outside the toolbar turns off the focusability of its items, so you don't have to tab through all items on the toolbar every time you want to go from the Search bar to the tab strip.

And while you can't drop off the toolbar with the arrow keys, you can drop off it with Tab/Shift-Tab (as with the tab strip, although there it drops you off immediately; maybe the Bookmarks Toolbar should behave the same).

Adding this keyboard access method allowed me to simplify further by removing the Bookmarks Toolbar menuitem, which was added primarily for accessibility over in bug 408938.

And replacing Smart Bookmarks with Bookmarks saves a "smart" amount of precious horizontal toolbar real estate for user bookmarks.

I wonder how far we could take this kind of change. Could we consolidate the History menu into the Back/Forward buttons dropdown menu? Could we get rid of the menubar entirely, integrating all menu-accessible functions into other UI (perhaps a command toolbar)?

Maybe the four menu commands (Bookmark This Page, Subscribe to This Page, Bookmark All Tabs, and Organize Bookmarks) could be buttons on the Bookmarks Toolbar for better discoverability and immediate accessibility (although it would take up more of that precious toolbar space).

thoughts on sheriffing

2008-02-27T11:51:00.000-08:00

I sheriffed yesterday, on the last day before the code freeze for Firefox 3, beta 4. Sheriffing is an unusual role within the Mozilla community in that it isn't distributed meritocratically. It's a shared responsibility of the development team, and you can be assigned to sheriff without a clue how to do it.

(That said, it's not clear how one gets on or off the roster. We'd benefit from a clear and simple policy here, like making it be the set of people who have checked in to Gecko and Firefox modules recently, or some other set that represents the most likely current stakeholders in the health of the tree.)

And it's a pressure cooker, with lots of hard decisions to make, plenty of chances to screw things up, and a bevy of developers clamoring for a more or less open tree depending on their individual circumstances and biases.

Nevertheless, it's great training in making hard decisions under pressure (with the safety net of revision control, unlike in the real world, where you can't uncut the red wire), and there are plenty of people helping out with advice and assistance with the chores of sheriffing.

Reed Loden and David Baron, in particular, were a huge help to me yesterday in tracking down regressions, backing out patches, filing bugs, and the like. And David ultimately took on the last leg of sheriffing when we extended the freeze a few hours to make up for a late tree closure (the third that day). Thanks guys!

(Thanks too to Matthew Zeier for jumping in at midnight to kick a box that was preventing the tree from reopening!)

Ultimately, despite the difficulties associated with an all "volunteer" force, I don't think I would professionalize the sheriff role. The tree is our shared treasure, and sheriffing is a great eye opener to the project-wide costs of individual mistakes and the value of good tree etiquette, helping us develop into better stewards of the source. I think it's worth the pain, but for a different perspective, see dougt's thoughts.

Update: dougt's blog post has since been removed, but he's expressed his current thoughts on the subject in a comment on this post.

better MDC searches from the search box

2008-02-06T15:07:00.000-08:00

I had an "MDC (English)" search plugin (not sure where I got it from), but it wasn't returning the Observer Notifications page when I searched for "xpcom-shutdown". Turns out it was using the old search engine instead of the new Nutch-based one, so I created a plugin that uses Nutch instead and uploaded it to Mycroft. Grab it from there if you want better MDC searches from the search box.

Update: the search plugin built into MDC now uses Nutch, so you can now simply install that one by going to MDC and then clicking the glowing icon in the search box.

keeping up with the Joneses

2007-12-17T12:11:00.001-08:00

I thought I'd mention a couple blogs I follow to keep abreast of what is happening with other browsers.

First, Bernie Zimmerman (author of the GrayModern theme) tracks news about multiple browsers at his Browsersphere blog. Second, WebKit and Safari news has long been available at Surfin' Safari, although I suspect the WebKit part of that will slowly move over to the new Planet WebKit.

What blogs do you read to track the coopetition?

Video of Joseph Smarr on High Performance JavaScript

2007-11-29T11:43:00.001-08:00

Last month Joseph Smarr, Chief Platform Architect at Plaxo, came to the MoCo office to talk about High Performance JavaScript: Why Everything You've Been Taught is Wrong.

Joseph has tons of experience optimizing JavaScript for a large-scale AJAX application and gave a great presentation chock full of useful info for web app and Firefox chrome developers on improving the performance of JavaScript-based applications.

A video of Joseph's presentation is now available, and the presentation slides are also online, so check it out. Unless you've already seen it or are Joseph, you're going to learn something.

Alt-Tab-like history navigation

2007-11-15T03:15:00.001-08:00

Here's an idea for an extension that I'll probably never get around to writing (but one of you might, perhaps for the extension contest!):

Overload Alt-(Left|Right)Arrow, the history back and forward keyboard shortcuts (Cmd-Arrows on Mac), to create an Alt-Tab-like experience with a row of thumbnail previews to which you can navigate by holding down the Alt key, pressing the arrow keys multiple times until you reach the target page, and then releasing the Alt key.

In other words, do the same thing for history navigation that Dão Gottwald is doing for tab navigation with his Ctrl-Tab extension.

(Bonus points for version 2: track non-linear meanderings and expose them as parallel tracks to which you can navigate with the up and down arrows.)

tabs for Thunderbird 2.0.0.9

2007-11-15T00:26:00.001-08:00

Anticipating requests, I've spun some tab-enabled builds of the latest version of Mozilla's mail/news desktop app for Linux, Mac, and Windows.

Note that the Mac version is no longer compatible with Mac OS X 10.2, as my Mac build machine (a.k.a. my laptop) has been upgraded to Leopard and XCode 3.0 and no longer has the 10.2.8 SDK on it. It should work on 10.3.9+, 10.4, and 10.5, however.

p.s. Congrats to the Thunderbird team on the release of 2.0.0.9! Getting a security and stability release out the door is no mean feat, requiring careful coordination between several groups of talented folk with a high standard for software quality that they consistently achieve. Bravo!

Mac OS 10.5 First Glance

2007-10-31T02:12:00.001-07:00

I spend most of my time in an Ubuntu VM, so I don't use many of the features of my MacBook Pro's host OS. But I upgraded to 10.5 yesterday for dtrace and checked out a few other features in the process.

Spaces

Spaces works about as well as VirtueDesktops. It's easier to configure, and it's less crashy, but it doesn't let me give my spaces names, which has been a palpable visual cue in VirtueDesktops that I've landed on the right one.

And although moving to the right of the rightmost space usefully wraps around to the leftmost one, the transition animation shows me moving left (but not across the intermediate spaces), which confuses me every time.

But most significantly, like VirtueDesktops it makes navigating to a window even more complex than it already was, with three somewhat-overlapping keyboard shortcuts: Control-ArrowKeys to change spaces, Command-Tab to change applications (across all spaces), and Command-BackQuote to change windows within an application.

I'm constantly hitting the wrong key. Maybe I'll get used to it, but I think I'll continue to prefer how I've configured multiple desktops in Ubuntu, where one shortcut (Control-Alt-ArrowKeys) switches between desktops and another (Control-Tab) switches between windows on that desktop. I wish there was a way to do that on Mac.

Time Machine

Time Machine looks like it could replace the manual backups I currently do with SuperDuper!. It seems to lack a "back up everything now" button, which I want to press before leaving for a trip, but perhaps its automatic hourly backups are good enough.

Nevertheless, it's unclear when and how it'll back up my 40GB Ubuntu virtual disk file, which is almost always open. Maybe I could exclude that file from Time Machine backups and then back up the files inside it from within the VM.

Unfortunately, there's no Time Machine (or even SuperDuper!) for Ubuntu, as far as I can tell, just a hundred blog posts describing how various smart folks have used some arcane combination of tar and rsync commands to back up their systems.

Networking

The Network preferences dialog is much better organized, which is nice, since I seem to visit it more often than I'd like. But perhaps I'll be visiting it less now that Mac OS X no longer turns up its nose at my home network's WPA personal security after every taste of the office network's WPA2 enterprise security.

The WPA2 enterprise username/password dialog also no longer goes away while I'm in the middle of filling it out if I take more than three seconds to do so, a welcome change.

VMWare Fusion

VMWare Fusion has a few minor issues in 10.5. It no longer resizes my Linux VM's resolution when I plug my laptop into my external monitor, nor does it recenter the desktop when I go from the external monitor back to my laptop's display until I switch from full screen mode to window mode and back.

And using Command-Tab to go to Fusion alternates between open Fusion VMs on two different spaces instead of taking me to the last one I used. Plus the tools need some munging to properly integrate with X.

But on the whole it still works fine, and I can continue to live in my full-screen Linux VM (from where I'm typing up this blog post now).

Appearance

I like the new darkness, with its multitude of gray tones. But I bemoan the addition of even more rounded edges, like those at the bottoms of menus. I prefer sharp edges in both virtual designs and physical ones (like cars and clothing), and its too bad everything has become a blobject since computers made it easy to draw a spline. Bubble buttons, bubble cars, bleh.

automated JS code rewriting

2007-10-15T15:53:00.001-07:00

Taras Glek has been doing awesome work on a framework for automated C++ code rewriting. I'd love to see something like that for JS code, since there are potential optimizations that are hard to do by hand (like changing the way we memoize nullary methods or removing the names of function expressions assigned to object properties).

Maybe Narcissus could be repurposed to provide round-trip JavaScript parsing, modification, and reserializing? This'd be a great project for someone who wants to help improve Firefox performance.

Bo Yang's Advanced Microsummary Builder

2007-10-04T00:41:00.000-07:00

This summer Bo Yang, a student at NanKai University in Tianjin, China, worked on a microsummary builder extension. His goal was to make it easy for regular users to create custom live titles for pages while experimenting with some additional features for power users.

He's recently uploaded the extension to addons.mozilla.org, and I've created a screencast showing it in action. Check out the screencast, then try out the extension (Firefox 3 pre-releases or nightly builds only).

Don't forget to file any bugs you find, and let Bo know (in comments on this blog post or by emailing him directly) what kinds of pages you're summarizing and how the extension works for you.

(For example, I used it to create a live title of timeandate.com's World Clock page showing the approximate time in Bo's time zone so I knew when I could expect to see him online.)

tabs for Thunderbird 2.0

2007-09-20T05:06:00.000-07:00

A user of one of the "Thunderbird 1.5 with tabs" builds I made a couple years ago recently asked me if it would be possible to update the patch for Thunderbird 2.0. After some wrangling, I got the patch to apply and behave itself in my testing, and I've spun some tab-enabled builds of 2.0.0.6 for Linux, Mac OS X, and Windows.

Note that the Thunderbird developers are implementing a different version of tabs for Thunderbird 3 over in bug 218999. So I won't be porting this patch to the trunk. But if you can't wait for that release to get your tabs, these builds may be useful to you.

To open a message in a tab, context-click it and select "Open message in new tab" from the context menu. To make this the default behavior when opening messages, set Preferences > Advanced > General > "Open new messages in" to "A new message tab".

p.s. congrats to Thunderbird on the new organization! I'm looking forward to great things from it.

Dave Winer's take on feed reading in Firefox

2007-08-17T14:31:00.001-07:00

Dave Winer came to MoCo yesterday for a chat about feed reading.

He gave us some food for thought, in particular the idea that limiting Firefox's feed reading functionality to a mere conduit for transferring feeds to the user's third-party reader of choice doesn't meet the needs of users who don't already understand the benefits of aggregated feed reading (which may well be a large majority of users).

Dave suggested we instead integrate feed reading directly into Firefox (while preserving choice for users who want to use another app). I'm inclined to agree, but I'll note that there's a third option: we could simply choose a default third-party feed reader, just as we've chosen a default search engine, and direct users there when they click on a feed.

it's not just about Thunderbird

2007-07-27T04:26:00.001-07:00

Folks seem to have missed half of Mitchell's recent email call to action. It wasn't only about finding a new home for Thunderbird.

Mitchell also says that "we would also like to find contributors committed to creating and implementing a new vision of mail" and that "Mozilla has a range of resources - funds, code, etc. - that can be applied to this problem. We're looking for people with expertise, vision and leadership capabilities."

MoCo's raison d'être isn't Firefox, it's improving the Internet through Firefox and other initiatives. That's why it's investing in the mobile space with projects like Joey, and it's why Mitchell and others (like me) are interested in mail.

But Thunderbird only has 5-10 million users (including me), while Firefox has 100 million, which means that at least 90% of Firefox users (and many more users of other browsers) are not being helped by Thunderbird.

That's not because MoCo hasn't invested enough into Thunderbird, it's because Thunderbird isn't the right solution for those users. And, based on its development trajectory to date, I don't expect that to change.

But neither do the other extant mail apps serve their users particularly well. As Mitchell says, we need a new vision for mail, and for me it's one that combines the portability of webmail with the usability of a desktop app and provides innovative new features for presenting and participating in conversations.

So let's not only focus on what to do with Thunderbird, let's also figure out what to do about mail and how to do it.

multi-OS builds from one source tree

2007-06-11T07:35:00.001-07:00

Someone asked me recently about the tabmail patch for Thunderbird, and, in some spare time between the super-intensive Hungarian language classes I was attending the last two weeks, I thought I'd see what it would take to get the patch working in Thunderbird 2.0.

I also figured I'd take the opportunity to switch my Windows build environment from the old Cygwin-based environment to the new MSYS-based MozillaBuild environment and--following roc's lead--try to set up a shared source directory on my Mac laptop that my Linux and Windows Parallels-based VMs could build from.

Setting up an SMB/CIFS share in Mac OS X via Apple > System Preferences > Sharing was trivial.

And mounting the share in Linux also proved fairly easy. I just had to install the smbfs package (available from Applications > Configuration > Synaptic Package Manager in Ubuntu 6.10) and then use Linux's standard mechanisms for mounting to an arbitrary filesystem location, f.e. via the smbmount command:


smbmount //10.211.55.2/myk ~/Machome -o username=myk

Note: you need to setuid on the smbmnt and smbumount binaries to be able to mount as a non-root user.

Getting things working on Windows proved harder, however. I tried to use mount to mount the share:


mount \\10.211.55.2\myk /home/myk/Machome

But mount complained "function not implemented", and googling for a solution proved unfruitful.

Then I tried adding a mount point to /etc/fstab per the instructions in /etc/fstab.sample, which got MSYS to mount the share (after also restarting Windows, since MSYS only parses /etc/fstab on DLL initialization), but then cl mistranslated a filename on the share and died with this error:


cl -Fohost_cppsetup.obj -c -TC -nologo -Fdhost_cppsetup.pdb -DXP_WIN32 -DXP_WIN
-DWIN32 -D_WIN32 -DNO_X11 -Ox -MD           -DINCLUDEDIR=\"/usr/include\"
-DOBJSUFFIX=\".obj\"   -I../../dist/include/mkdepend -I../../dist/include
-I../../dist/include/nspr    -I../../dist/sdk/include -I../../dist/include/nspr
/home/myk/Machome/Projects/bonecho/mozilla/config/mkdepend/cppsetup.c
cl : Command line warning D4002 : ignoring unknown option
'//10.211.55.2/myk/Projects/bonecho/mozilla/config/mkdepend/cppsetup.c'
cl : Command line error D2003 : missing source filename

I thought perhaps I could fool cl with a symbolic link:


ln -s /home/myk/Machome /home/myk/Machome2

But MSYS's version of ln apparently copies the directory (and all its contents) instead of linking to it (at least for network shares).

Finally I discovered that I could map a drive letter to the share in Windows Explorer > Tools > Map Network Drive, which MSYS (after restarting Windows again) maps to a path (/z in my case) that--although it's not where I want it--at least doesn't get screwed up by cl.

So now things are (almost) working. But not quite, as I'm seeing strange build errors like this one (when trying to build Firefox on the trunk):


/c/mozilla-build/moztools/bin/nsinstall -m 644 _xpidlgen/mozIPersonalDictionary.h _xpidlgen/mozISpellCheckingEngine.h _xpidlgen/mozISpellI18NUtil.h _xpidlgen/mozISpellI18NManager.h ../../../dist/include/spellchecker 
make[5]: Leaving directory `/home/myk/Projects/minefield/build/firefox-opt/extensions/spellcheck/idl'
make[5]: Entering directory `/home/myk/Projects/minefield/build/firefox-opt/extensions/spellcheck/locales'
make[5]: Leaving directory `/home/myk/Projects/minefield/build/firefox-opt/extensions/spellcheck/locales'
make[5]: Entering directory `/home/myk/Projects/minefield/build/firefox-opt/extensions/spellcheck/myspell'
make: Entering an unknown directory
make: *** src: No such file or directory.  Stop.
make: Leaving an unknown directory

And this one (when trying to build Thunderbird with the tabmail patch against the 2.0.0.4 release tag):


/c/mozilla-build/moztools/bin/nsinstall /z/Projects/bonecho/mozilla/xpfe/bootstrap/showOSAlert.cpp /z/Projects/bonecho/mozilla/toolkit/xre
nsinstall: cannot copy z:\Projects\bonecho\mozilla\xpfe\bootstrap\showOSAlert.cpp to z:\Projects\bonecho\mozilla\toolkit\xre\showOSAlert.cpp: Access is denied.

So I'm still working on building on Windows.

FWIW, build times feel OK on Linux and bad (but tolerable, for occasional use) on Windows, where initial build configuration and CVS operations seem particularly slow.

Speaking of CVS operations, I edited MozillaBuild's start-msvc71.bat file to start ssh-agent so I wouldn't have to enter my SSH key for every CVS transaction:


start "MSYS Shell - MSVC7.1 Environment" "%MOZILLABUILD%\msys\bin\ssh-agent"
"%MOZILLABUILD%\msys\bin\rxvt" -backspacekey  -sl 2500 -fg %FGCOLOR% -bg %BGCOLOR%
-sr -fn "Lucida Console" -tn msys -geometry 80x25 -e /bin/bash --login -i

Note: unlike in Cygwin, ssh-add in MSYS only registers ~/.ssh/identity by default. To get it to register your SSH v2 DSA private key, you have to specify the path to that key on the command line, i.e.:


ssh-add ~/.ssh/id_dsa

FWIW, MozillaBuild is a dream to install compared to the old Cygwin-based environment, but I miss the more Unixy Cygwin, not to mention the much more functional Puttycyg terminal.

The Importance of Good Translation

2007-05-02T00:51:00.001-07:00

A Hungarian and an American were walking down the street, both of them wishing they were holding hands. They'd been teaching English in the same Hungarian school for months, and they'd grown quite fond of each other.

The American was talking about a man she knew, and the Hungarian grew worried about this potential rival. "Did you two have a romantic relationship?" he eventually asked pensively.

"No," the American reassured him, "it was platonic."

The Hungarian was crushed. In the Hungarian language, a plátói relationship is an unrequited one, in which the pair still pines for each other. Quite different from common usage in English to mean a relationship devoid of romantic attraction.

So they didn't hold hands that day or any other for a year until they discovered the misunderstanding. All because of that single error in translation.

Fortunately, they did eventually discover the error, and last I heard, they were getting married.

toolsmith opportunity at Mozdev

2007-04-30T12:48:00.001-07:00

The Mozilla-related job market seems to be heating up these days, and I even received an inquiry from a recruiter lately asking if I know of (or am) someone to hire.

Job postings from that recruiter (and others) are available on mozilla.jobs, and the Mozilla Corporation is also hiring, but I'd like to highlight something else: a Web Apps Developer/Sysadmin contract position at Mozdev.

Mozdev provides project hosting and development tools to Mozilla-related projects, and we're looking for someone to enhance and integrate the services we provide.

This is a fantastic opportunity for an engineer's engineer who really appreciates the value of good tools in the software development process and wants to implement and integrate the state of the art collaborative development tools (VCS, wiki, forum, bug tracking, etc.) and push the toolsmithing envelope.

If you know of (or are) the right person for this job, then don't hesitate to apply!

MTV returns to HTML

2007-04-30T11:01:00.001-07:00

According to Bernzilla, according to SimpleBits, according to MTV Labs, mtv.com has switched back to an HTML-based site from the Flash-based site they implemented nine months ago.

tab-specific mute

2007-04-24T03:12:00.001-07:00

I've heard from a number of folks that it'd be very useful for Firefox to let you mute a particular tab in the browser, since more and more sites are incorporating music or other audio content, and users are leaving more tabs open in the background, and they don't necessarily want to hear those tabs while listening to tunes or working.

So I looked around for a way to do this (ideally something I could integrate with site-specific preferences, so you could specify which sites are allowed to quack), and the closest I could find is FlashMute, a small Windows app written by Einar Otto Stangvik that mutes all Flash (and other browser-based sound).

It's like a global mute for browsers, and although it isn't open source, its author says it will be once he gets around to pushing it to Google Code.

But it doesn't let you mute individual tabs, much less specific sites, so it's not quite the feature folks have been clamoring for. So I asked around a bit, and smart folks seem to think it would be very hard to well nigh impossible to implement this on Windows, except possibly on Vista with major changes to our plugin architecture.

Anyone know different or know what the situation is on other platforms?

Site-Specific Preferences, Take 0.3

2007-04-24T01:25:00.000-07:00

The Content Preferences extension version 0.3 is now available from the AMO sandbox.

I added these user-facing enhancements:

a site-specific Page Style setting for sites like dbaron.org that provide alternate stylesheets;
a site-specific Character Encoding setting for when Firefox incorrectly guesses the encoding on a site;
a Reset All button at the bottom of the sidebar that lets you reset all settings to their default values for the current site;
a Global tab that lets you set preferences that apply to all sites;
a yellow background color behind modified settings that helps you identify the settings you've twiddled;
a Reset button () next to modified settings for setting them back to their default values (thanks to Mark James for the icon, which comes from his Silk icon set).

Props to Alex Faaborg for his feedback on and assistance with several of these enhancements and to Dan Mosedale for pointing out the spiffy way OmniWeb lets you reset modified settings.

I should note that while I implemented site-specific Page Style (primarily to exercise the back-end code) in a way that could be integrated into the Firefox core, I think it would make more sense to move the entire Page Style feature out of the core and make it available only as an extension, given how rarely the feature is used.

But, as Mike Connor pointed out to me recently, UI for selecting an alternate stylesheet is actually mandated by the CSS 2 spec (section 3.2, point 5), and if we have to include it, we might as well make it work better.

On the back-end, the extension sports the following enhancements:

a declarative syntax (modeled after the one used by the Preferences dialog) for describing widgets in the sidebar, which the sidebar controller uses to auto-update prefs when users twiddle widgets (and vice-versa);
nsIObserver-style notifications from the service and the controller;
DOMContentLoaded notifications from the controller, in addition to the location change notifications, to support settings like Page Style that need to do their thing after the page has loaded;
nsIVariant pref values stored as blobs in the database, for theoretical round-trip integrity to the database and beyond, err, back;
auto-derivation of sites from URIs inside all service methods, so instead of calling getSiteForURI to derive the site and then a second method like getPref to do some actual work, you just call the second method, passing it the URI, and let the service do the deriving.

I also fixed a number of miscellaneous bugs (and undoubtedly introduced new ones) and worked around a few bugs in Firefox. Many thanks to John P. Baker for spotting some of the problems and providing useful feedback on the API.

Per the Firefox 3 product plan, my next step will be to integrate the core service and site-specific text zoom into the browser core, for which I've filed bugs 378547 and 378549, respectively.

The sidebar, on the other hand, and the other two settings it exposes will remain an extension for now.

The End of the URL?

2007-03-28T17:17:00.000-07:00

I was listening to BBC news radio last night when the announcer said to "type World Business Report into the search engine and follow the link from there" for the latest version of the report.

He followed up by mentioning the BBC's news domain name (~~bbc.co.uk~~ bbcnews.com) as an alternative, but it was striking that he considered "the search engine" a more reliable path to the program's page.

Of course, the actual URL for that page is pretty long, and it isn't available directly from the BBC news home page or even from its Business page, so he's probably right.

For Google and MSN, anyway, both of which return the report as the second search result (the first being the BBC's other World Business Report, a TV program).

Yahoo, on the other hand, returns the Wikipedia entry describing the TV program as its first result. The radio program page is below the fold (on my monitor) as the fourth result.

microsummaries for the Summer of Code

2007-03-26T13:26:00.001-07:00

I've added three microsummary-related projects to Mozilla's Summer of Code project list:

rich content microsummaries: support for HTML and image-based microsummaries
microsummary builder: a tool to make microsummaries simpler to create (for both regular users and developers)
microsummary generator web service: integration with a generator repository, including auto-notification and easy installation of available generators for the sites you browse

The deadline for applying to hack on one of these projects is today at 5pm PDT (midnight UTC), which is just hours away, so if you're interested in tackling one of these, don't delay!

Content Preferences - Architecture/API

2007-02-14T16:39:00.001-08:00

The content preferences code currently has a four piece architecture:

a service that manages the database of prefs;
a controller for each window that watches the browser's location and notifies pref handlers when it changes;
pref handlers that tweak the browser according to the user's prefs;
a sidebar housing controls for twiddling prefs.

In the first version of the extension, I designed these to support preferences like the text zoom pref. In v2 I redesigned them to improve that support and tried to generalize the API to work for other prefs.

But a single caller is a very limited perspective for designing an API (indeed, I've already found issues while getting a second pref up and running on it), so I'm keen to get feedback on how to make this work well for other prefs (in both core code and extensions).

Here's how it works at the moment:

The Service (mozISitePrefService)

The service manages the database of prefs. Its API is pretty simple. It has four core methods, getPref, setPref, hasPref, and removePref:

mozISitePref getPref(in AUTF8String site, in AUTF8String key);
void setPref(in AUTF8String site, in AUTF8String key, in AUTF8String value);
boolean hasPref(in AUTF8String site, in AUTF8String key);
void removePref(in AUTF8String site, in AUTF8String key);

It also has a method, getPrefs, that gets all prefs for a site, and it has another method, getSiteForURI, that extracts a site identifier from a URI:

void getPrefs(in AUTF8String site, 
                   out unsigned long prefCount,
                   [retval, array, size_is(prefCount)] out mozISitePref prefs);

AUTF8String getSiteForURI(in nsIURI uri);

Site identifiers are full domains by default (f.e. www.mozilla.org), but you can configure the extension to use base domains (f.e. mozilla.org), and perhaps we'll cook up other options in the future.

The interface to a preference (mozISitePref) is very basic:

readonly attribute AUTF8String site;
readonly attribute AUTF8String key;
readonly attribute AUTF8String value;

The Controller (SitePref)

The controller's job is to notify pref handlers when the browser location changes so those handlers can apply the user's preferences for the new location. It has addObserver and removeObserver methods that handlers can use to register/unregister themselves for notifications:

addObserver(in AUTF8String key, in nsISupports observer)
removeObserver(in AUTF8String key, in nsISupports observer)

The methods take a pref key so the controller know what setting the handler cares about. When the location changes, the controller grabs the set of prefs for the new location and calls each observer's onLocationChange method with the pref it cares about (if any):

onLocationChange(in nsISitePref pref)

The Pref Handlers

The pref handlers implement the aforementioned onLocationChange method and then do whatever they need to do to apply user preferences to the browser.

The Sidebar (chrome://cpref/content/sidebar.xul)

The sidebar provides a central location for site-specific preference controls. It's an experiment in exposing these preferences in a place that is location-specific (unlike the Preferences dialog) and visible alongside the page being affected (unlike the View menu).

It doesn't do much besides provide a place for pref controls to overlay themselves onto. Controls are responsible for updating themselves when the location changes. But the sidebar does define a gMainWindow shortcut for getting the browser window that the sidebar is embedded in.

Feedback

I'm interested in feedback on all aspects of this API. Here are the questions I know I should ask:

Should pref values be typed?

We can't store them typed in the database given the EAV model we're using to store them (although we could change the model if it mattered enough), but we could convert them on their way in and out of the database and have type-specific methods for getting and setting them (à la nsIPrefBranch).
Should pref handlers listen for location changes themselves and get their prefs directly from the service instead of having that work be mediated by the controller?

It's faster for the controller to query once for all prefs, and it's simpler on the pref handlers not to have to implement nsIWebProgressListener themselves, but it makes the architecture more complex, since it adds an extra layer between the service and the handlers.
Is AUTF8String the right string type for site identifiers and keys?

And then there are all those questions I don't know I should be asking (along with their answers), so clue me in!

Content Preferences - take 2

2007-02-13T08:54:00.001-08:00

I released an updated version of the Content Preferences extension today.

This update features significant changes under the hood to improve the API for extensions that want to use it to store their own site-specific prefs (about which more shortly).

It also offers the following two improvements for end-users who use it for its text-zoom functionality:

Text zoom changes via the mousewheel are now supported, so no matter how you change your text zoom (via the View menu, keyboard shortcuts, the sidebar slider provided by this extension, or mousewheel gestures), this extension will save your setting for each site you visit.
An experimental mode lets you set preferences for a domain and all its subdomains. (f.e. *.mozilla.org). To enable this mode, use about:config to set the extensions.cpref.siteMode preference to the number 1.

If you're trying out the Gran Paradiso Alpha 2 release (or trunk nightlies), the extension uses the new "effective TLD service" to correctly determine the base domain for each site (f.e. mozilla.org for www.mozilla.org and bbc.co.uk for www.bbc.co.uk). Otherwise, it falls back to the "top-level domain plus one segment" rule (i.e. mozilla.org for www.mozilla.org and co.uk for www.bbc.co.uk).

Give it a try, and let me know what you think.

Three Things I Love About Komodo

2007-02-02T16:50:00.000-08:00

Last week ActiveState released version 4.0 of their Komodo IDE (and announced Komodo Edit, a new free-as-in-beer version of the app). Komodo, like Songbird and Democracy, is Mozilla-based, and I've been using it as my primary editor for several years.

Here are three things I love about it:

Tabs

Like Firefox with web pages, Komodo uses tabs to present multiple documents in a single window. Tabs blows away every previous MDI approach for usability, and I wince whenever I have to use an application (TextWrangler, emacs) that presents multiple documents in any other way.

Indentation Adjustment

This may sound trivial, but Komodo has the easiest keyboard shortcut for adjusting indentation of any editor I've ever used. Just select the lines (or portions thereof) you want to indent and press the Tab key. To unindent, press Shift-Tab.

Komodo will indent using tab characters or spaces per your settings (which you can set for individual files) or by sniffing out the indentation strategy already in use in the file.

Fully-Configurable Key Bindings and Syntax Highlighting

I almost never tweak these settings, but it made a big difference to be able to do so when I first started using the application.

In Komodo, every keyboard shortcut is configurable, which I used to change "Find Next" from F3 to Ctrl-G and "Go to Line" from Ctrl-G to Ctrl-L to match what I was used to from previous editors.

Syntax highlighting is also customizable--including font family, size, color, and background color--down to individual language elements, so you can give JS variables, HTML attributes, and Python comments their own individual styles.

Komodo also provides an Emacs key binding scheme and a Vi compatibility mode, if that's your thing. And it includes several built-in highlighting schemes, so you don't have to design your own from scratch (I started with "Dark" and made a few tweaks).

Everything Else

There are tons of other things to love, of course, like integrated debugging for half a dozen scripting languages, remote file access via S/FTP or SCP, code completion, background syntax checking, integrated source control for CVS, SVN, and Perforce, and so on.

And then there are the features I haven't learned to love yet, because they're new in version 4.0, but which I expect to come to rely upon in the future, like support for Firefox-style extensions.

Did I mention that it's cross-platform (Windows, Mac, and Linux)? If you're looking for a great text editor/IDE, check it out.

cool vs. useful

2007-01-09T11:25:00.000-08:00

Software engineers love cool new features, because programming is hard, and a cool hack represents a triumph of ingenuity and skill against the odds.

But computer users tend to prefer useful features to cool ones, because they use computers in order to get things done, and useful features help them do that.

Unfortunately, many apps suffer from an overfocus on cool, but I'm pleased to note (in a super-unscientific survey) that Google Groups reports only 24 results for the word "cool" in the mozilla.dev.apps.firefox newsgroup, where engineers and others discuss the development of Firefox, whereas "useful" appears in 85 posts.

Who Gives This Software to be Web?

2006-12-19T03:39:00.000-08:00

When my sister got married, I gave her away. But the pastor who officiated wanted to retain something of the tradition of parents performing that act, so when I walked my sister up to him, he asked me, "who gives this woman to be wed?"

And I responded "her father, her mother, and I do, sir."

For some reason I'm reminded of this story whenever I think about the three informal personas that guide my hacking.

Persona #1: My Mother

My mother is a novice computer user. She doesn't use keyboard shortcuts, and she doesn't use menus much either. Nor bookmarks, except for the couple I added to her Bookmarks Toolbar once. She also doesn't quite get the difference between a URL and a search, so she goes to URLs by searching for them on Google. She has never installed an add-on.

My mother doesn't care how or why her computer does what it does, and she doesn't want to bother learning how to use it better. She just wants it to do what she wants.

Persona #2: My Partner

My wife Judy, on the other hand, is a power user. She uses some keyboard shortcuts, and she uses a lot of bookmarks (organizing them into multiple categorized folders). She knows the difference between URLs and search terms. She groks HTML. And she has installed a couple of add-ons.

Judy takes the time to learn how to use her computer well, not because she wants to, but because she uses her computer a lot, and learning how to use it better helps her get her work done. She too doesn't care why her computer does what it does, she just wants it to work well for her.

Persona #3: Me

I'm a programmer. I spend more time computing than I do sleeping. So, like Judy, I invest time into making my computing environment as efficient and effective as possible, learning bunches of keyboard shortcuts, installing dozens of extensions, setting up multiple desktops, etc.

But I'm also fascinated with computers and how they work, and I like to modify apps to do more or do it better. So factors such as extensibility matter to me in a way they will never (directly) matter to most other people, although others will benefit from the extensions I and other programmers create.

He-Fox and the Masters of its Universe

I think software like Firefox can and should serve multiple audiences well, including the people I mention above, which comprise three basic categories of computer users. Not every feature will appeal to every group, and we might use even common features in very different ways, but Firefox should be able to provide a great experience for all three kinds of users.

When I work on Firefox and other apps, I try to keep these people in mind as proxies for Firefox's actual userbase and provide the appropriate experience for each one. So when considering who benefits from the work I do, I can say "my mother, my partner, and I do, sir."

userstyles.org creates microsummary generator repository

2006-12-13T13:10:00.000-08:00

Jason Barnabe has integrated support for microsummary generators into his userstyles.org site. I've uploaded all my generators to the site, and some other folks have uploaded theirs, so it's turning into a one-stop shop for microsummary generators. Check it out at:

http://userstyles.org/livetitle

persistent, site-specific prefs prototype

2006-12-12T04:33:00.000-08:00

I've been investigating options for improving user control over content, including persisting user decisions about appearance and behavior and overriding global preferences on a site-specific basis.

To test some ideas about how to do these things, I put together a prototype that implements a basic service for persisting site-specific preferences to a profile database.

The prototype also includes some experimental UI in the form of a sidebar into which controls for twiddling site-specific preferences can be placed. The sidebar currently contains one such control: a slider that sets the text zoom value (i.e. what View > Text Size > Increase/Decrease/Normal sets).

I've bundled up the prototype into an extension called (boringly) Content Preferences for Firefox 2 and up and posted it to addons. While it undergoes review on that site, the eager among you can get it from my web site: Install Content Preferences.

It should go without saying that this is early, rough alpha code, and you should exercise all due caution when testing it. To try it out, do the normal install and restart thing, then select View > Sidebar > Content Preferences.

Your feedback is welcomed.

---

Some voluminous notes for the compulsive informaddicts among you:

View > Text Size Impact

Once you install the extension, the View > Text Size menu items and their keyboard shortcuts also become site-specific and profile-persistent (i.e. lasts as long as your profile does). So even if you never open the sidebar, you still get the benefits of the extension with the existing text zoom UI.

If you uninstall the extension, that UI goes back to the way it was before (i.e. tab-specific and tab-persistent). No permanent harm done (AFAICT, YMMV, etc.).

The Slider

The sidebar slider's magnification range is 1-400%, which is somewhat smaller than the View > Text Size commands' range of 1-2000%, but the smaller range seemed more usable. The slider will follow any changes you make via View > Text Size as far as it can, then it'll sit there lonely at the end of its range until you come back to it.

What is a Site?

A "site," for the purposes of this early prototype, is the set of pages hosted at the exact same domain name (f.e. everything on en-us.www.mozilla.com).

As David Baron has pointed out, figuring out what constitutes a site is an important component of an endeavour like this, so future prototypes will experiment with TLD+1 (*.mozilla.com) sites, www-optional sites (www.mozilla.com == mozilla.com), and anything else that seems promising.

Perhaps multiple domains secured by certificates granted to the same organization should count as one site?

Fixing Font Size on the Web

Finally, I'm aware of multiple proposals for fixing the font size settings in Firefox so they're easier to use and get things right more of the time. And I'm also aware that the more we can get stuff like font size right without making users configure it themselves, the better.

This prototype doesn't constitute a proposal for dealing with font size, it's more an experiment in how to improve usability with persistence and site-specificity. I picked on text zoom only because itty-bitty fonts seem to be among the commoner complaints about the web, and also because hacking into text zoom seemed like a good testbed.

Even if we solve text size issues some other way, there will be other uses for the core service this extension provides. For example, Dave Camp overheard me describing this experiment a couple days ago and mentioned that he's been looking for a way for users to grant additional DOMStorage space to particular sites. A site-specific preference service sounds like just his ticket.

improving microsummary discoverability

2006-10-24T19:05:00.000-07:00

For Firefox 3, in addition to investigating our feature set for control over your web experience (about which more soon), I'm also looking into useful usability and functionality improvements to Firefox's support for microsummaries.

One glaring weakness is discoverability. In Firefox 2, it's hard to know if a page you're browsing has a microsummary, since you have to open the Add Bookmark dialog to find out, and you have to grok the significance of the drop-marker in the Name field.

Feeds, by comparison, are much more discoverable, since Firefox displays the feed icon in the location bar when a page provides a feed. Perhaps a similar mechanism would be useful for microsummaries.

To find out, I put together a prototype extension which displays an icon in the location bar when a web page has a microsummary.

When you click the icon, Firefox opens the Add Bookmark dialog and selects the microsummary as the "live title" for the bookmark.

Then just select the folder you want the bookmark to be created in (f.e. the Bookmarks Toolbar) and press the Add button to add a bookmark labeled with the microsummary for the page.

The extension is now available on addons.mozilla.org. Try it out with some of these sites and generators, and let me know what you think. Does the behavior make sense? What other behavior might we associate with the icon (f.e. drag-and-drop to the bookmarks toolbar)? What should happen when there are multiple microsummaries?

Notes:

The extension works in both Minefield and Firefox 2.0 and with both generated and site-provided microsummaries.
The location bar icon is intentionally blank, since I have no idea what kind of graphic should represent microsummaries. I would have made it colorless, too, but then it would have been invisible.
I named the extension something generic because I plan to prototype additional enhancements in future versions of it.
Adding an icon to the location bar for every interesting piece of content, especially in the age of burgeoning microformats, probably won't scale, so this may well be the wrong solution for the problem.

folks who made microsummaries happen

2006-10-24T16:22:00.000-07:00

My primary responsibility for Firefox 2 was to implement support for microsummaries. It was a large task, and I couldn't have done it without significant assistance from a number of other folks.

Mike Connor and Mike Beltzner saw the potential early on and encouraged me to work on microsummaries for Firefox 2. Both also helped in innumerable other ways, including code, user experience, and nomenclature reviews.

Mike Shaver provided invaluable early feedback, including coming up with the name "microsummary".

Ben Goodger and Brett Wilson helped me navigate the treacherous waters of the bookmarks code (and the gentler shoals of Places) to get the architecture and integration points right.

I'm extremely appreciative of the many hours Boris Zbarsky spent working through complicated technical issues with me, particularly how to download and parse an HTML page in Firefox without any front-end impact. Boris was incredibly helpful, and I've seen him do the same for many other developers. He's a real credit to the community.

Much props to Jonas Sicking, Dan Veditz, Darin Fisher, and David Baron for their thorough security review.

Eric Shepherd rocked the docs on many levels (writing, reviewing, organizing).

A veritable bevy of coders contributed patches: Dietrich Ayala, Simon Bünzli, Regis Caspar, Justin Dolske, Kevin Gerich, Pam Greene, Adam Guthrie, Joey Minta, and Phil Ringnalda.

And many other folks made microsummaries better by contributing bug reports, suggestions, microsummary generators, integration into blogging tools, and prototypes of future enhancements/add-ons.

Thank you, everyone!

(And apologies to those whose contributions I forgot to mention.)

content filtering, manipulation, and control in Firefox 3

2006-10-13T14:56:00.000-07:00

Over in mozilla.dev.planning, Deb has posted an article about Firefox's newly updated Feature Brainstorming list.

For the next version of Firefox, I'm going to take a particularly close look at the application's feature set for content filtering, manipulation, and control.

I'll look at the functionality Firefox currently provides, try to figure out what it should be providing (based on a variety of metrics), and identify a discrete set of changes (new features, enhancements, and even removal of existing code) which can provide evolutionary and/or breakthrough improvements to this area in the Firefox 3 timeframe.

I have a few ideas, which I've added to the brainstorming list; and others have added many more; but there are bound to be great ideas we haven't yet captured. So if you have some, please contribute them to the list!

a bunch of microsummaries news

2006-09-21T23:28:00.000-07:00

I've been remiss in not blogging lately about much cool microsummary news. To make up for it, here's a bunch all at once:

First off, Markdown Monkey, Deprec4ted, and NeoAddict have all created microsummaries for their web sites (the latter as a generator).

Also, I've added two new example generators, one that shows you flight status via FlightStats (prompted by a request from Seth Bindernagel) and another, adapted from a generator by Samuel Sidler, that shows you a web site's traffic ranking on Alexa.

Petr Tomasek has put together some microsummary generators (mostly for Czech sites).

And Dietrich Ayala, author of the way-cool Bugzilla Search generator, wrote an XSL stylesheet that transforms a generator into an HTML page containing a link for installing that generator (i.e. the generator displays its own install page).

I've added his stylesheet to all the example generators, so if you happen to load one of those generator files directly, you'll see something better than plain XML (unless you're looking for plain XML, that is, in which case you'll see something worse than plain XML, and View -> Page Source will become your friend).

Finally, I wrote a tutorial on creating regular expressions for a microsummary generator to help folks without existing RegExp fu learn to write expressions to match the URLs of sites they want their generators to handle.

woot.com provides microsummary

2006-07-10T17:30:00.000-07:00

woot.com now provides a microsummary of its home page showing the current product for sale on that site:

Three days ago I didn't even know woot.com existed. Now I not only know about it, I can see what it's selling every day with a glance at my bookmarks toolbar, and I've already bought something. Woot!

microsummaries talk at OSCON

2006-07-10T16:36:00.000-07:00

I'll be giving a talk on Microsummaries at the upcoming O'Reilly Open Source Convention (OSCON) on Thursday, July 27, from 11:35am - 12:20pm in the Portland 251 room. The talk will include an overview of microsummaries, a demonstration of their functionality in the upcoming Firefox 2 (including generators for popular web sites and sightings in the wild), a lightning tutorial on building a generator (à la this one), and discussion about future enhancements to benefit web sites and users.

It should be a fun and informative session, so please drop by if you're attending OSCON. And if you're still just thinking about attending, note that Benjamin Smedberg will also be talking about building apps with XULRunner, Mitchell Baker will be on a panel discussing open source projects and money, and Mark Hammond will be presenting on Python in Mozilla.

Other Mozilla folks are also attending, and there'll be a BOF, a booth, a screening, and probably other exciting events and get-togethers, so it's a great opportunity to meet Mozillans and learn more about the project. Check it out.

microsummaries beyond bookmarks

2006-07-06T18:30:00.000-07:00

Folks at my XTech talk on microsummaries in May seemed excited by the new feature, and in discussion they pointed out a number of potential applications for microsummaries technology, including:

Simplifying web pages for blind users who have to walk DOM trees via screen readers to access page content. One idea is to establish a repository of site-specific XSLT stylesheets that remove unnecessary content (f.e. redundant navigation) from pages, tag important content, and make other modifications to optimize navigability via screen readers.
Reorganizing web pages for mobile users with screen size and navigation constraints. A common problem on mobile devices is that users have to scroll past screenfuls of navigation to get to the content of a page, since the navigation appears before the content in the page. Here again we might establish a repository of XSLT stylesheets that move navigation to the ends of pages and do other transforms to make the pages display better on small screens.
Creating widgets that provide specific information or help you do particular tasks, à la Yahoo! Widgets, Opera Widgets, and Apple's Dashboard. XSL transforms probably aren't sufficient here but could be a component in an overall solution.

These are all great ideas, and I'll be keeping their use cases in mind as I refine microsummaries functionality in Firefox.

microsummaries in Firefox 2.0 alpha2

2006-05-15T07:43:00.000-07:00

The Microsummaries feature I proposed a few months ago in this blog--and have been developing since then--has landed in time to make Firefox 2.0 alpha2. Or rather, an initial version of it has landed. UI and other elements are still undergoing refinement.

But there's something to play with now, so play, and let me know what you think! To use the feature, you first have to install some microsummary generators, which are the things that extract microsummaries from their pages. Get started with this page of sample generators.

To install a generator from that page, just click its link (f.e. the Yahoo! Finance Stock Quote link), click OK when Firefox asks you if you want to add the generator, go to a page to which the generator applies (f.e. the Yahoo! Finance Stock Quote for Apple Computer), and then select Bookmark This Page... from the Bookmarks menu.

In the Add Bookmark dialog, select the microsummary from the Summary drop-down menu, then select the Bookmarks Toolbar from the Create in drop-down menu. Press the Add button to add the bookmark. A bookmark to the page should appear on your bookmarks toolbar (or its "chevron" overflow menu, if you're out of space on the toolbar proper) with the microsummary you selected as its label.

If you're having trouble, see this set of unit tests, which take you through step-by-step instructions for testing the feature. If you want to create your own microsummary generators, see this tutorial on the subject.

Up next: bug fixes, UI brainstorming, a presentation Wednesday at XTech, and perhaps a pre-alpha microsummary builder extension if I can get to it.

Easier Updating to the Latest Nightly Build

2006-03-15T04:51:00.000-08:00

I frequently fall behind on nightly trunk updates, usually because I brush off pending updates and then go for days before restarting Firefox. Occasionally it's because I'm away from my computer on vacation.

Once I'm behind, it's painful to catch up, since the app update service feeds updates to Firefox one day at a time, so I have to Check for Updates, wait for Firefox to find and download the next one, restart the app to apply the update, and then repeat the process over and over again until I'm finally up-to-date.

Bug 306864 is about fixing this on the server side by making the app update service hand nightlies a single update to the latest nightly build, but it doesn't have much traction, so I hacked up a dumb but effective client-side fix in the form of an extension that checks for updates, downloads them, applies them, and then repeats the process until Firefox is fully updated.

Using the extension is simple: just select Make Me Up-To-Date from the Help menu, and the extension will do its thing. Warning: it doesn't prompt you before restarting Firefox to apply an update, and it doesn't tell you what it's doing (except on the console). So make sure you know what you're doing before you use it (i.e. finish filling out and submitting web forms, save tabs you want to access afterwards, start Firefox with a console, etc.).

I've tested it with various Linux nightlies from the last couple months, and it worked as expected except when the app update service or client was busted. Since it uses the same backend components as the regular updater, if Check for Updates doesn't work, then Make Me Up-To-Date won't work either.

If you try it out, post a comment with your results, and include your starting and ending builds plus what platform you're on so I can get a sense of where it is and isn't working. And, of course, back things up in case this horks your build, since it's new, untested code, and it may well be buggy.

Install Make Me Up-To-Date 0.1

improving Firefox password saving

2006-02-13T02:12:00.000-08:00

Using Firefox's password saving functionality is a frustrating experience for me, and I suspect it's frustrating for other users too. It has several problems:

Problem #1: when Firefox remembers more than one password (or, more accurately, both a password and a username) for a given site, it doesn't autofill the login form or give me any clue what the usernames/passwords are until I correctly guess the first letter of one of the usernames.

Although I only have multiple accounts at a couple sites (principally those of two utility companies which made me create new accounts when I moved), I regularly enter my login info incorrectly and then mistakenly tell Firefox to remember it, so I now have invalid remembered passwords at a number of sites, and Firefox no longer autofills their login forms.

Problem #2: Firefox asks me whether it should remember usernames/passwords the moment I submit a login form, and it does so via a modal dialog, so I can't wait to see if my login attempt succeeded before deciding to save the info.

Problem #3: Deleting passwords is hard. It's only possible via the password manager, and every time I open the manager I have to rediscover how its list is sorted. Unfortunately the list turns out to be sorted by raw URL, so http://example.com/, http://www.example.com/, and https://www.example.com/ are all in different places on the list, and I have to hunt them all down to find the one(s) I'm looking for.

Fortunately, fixing these problems seems relatively straightforward.

First, when a user loads a login page for which Firefox remembers multiple username/password combos, the browser should display a non-modal status bar (similar to the popup blocker status bar) which lists the usernames and prompts the user to select one. When the user does so, Firefox should fill in the form and perhaps also automatically submit it. Here's a mockup of how it might look:

Second, when a user submits a login form with an unfamiliar username, Firefox should ask if the user wants to remember the info via another non-modal status bar, something like this:

Third, the password manager should support filtering, just as the cookie manager does, via a "Search" field that restricts the list to matching entries.

With these changes:

users will be able to see and pick between multiple remembered username/password combos for a given site;
users won't have to decide in advance whether to save that info; they'll be able to do so after seeing if their login attempts have succeeded;
users deleting passwords using the password manager will be able to filter the list to find just the passwords they want to delete.

As a beneficial side-effect, users will be able to ignore the "save this password?" question instead of being forced to answer it every time. And to make deleting passwords even easier, we might include UI for doing so right from the "pick an account " bar (f.e. a context menu item).

Thoughts?

microsummaries feature proposal and prototype

2006-02-07T10:02:00.000-08:00

After receiving some positive feedback on my "son of live bookmarks" idea, I wrote up a more comprehensive description and proposal for a Firefox feature that supports the display and updating of microsummaries of web page content (tip o' the hat to Mike Shaver for the term "microsummaries").

And then, since it's easier to understand a proposal with some working sample code, I hacked up a prototype in the form of an extension you can install into a Places-enabled build (milestone 2 or newer).

The prototype comes with built-in support for three kinds of microsummaries: eBay auction items, Yahoo! Finance stock quotes, and Merriam-Webster's Word of the Day. Just throw a link to one of those pages onto your bookmarks toolbar, and the prototype will start updating it regularly with pertinent information (the price/time left in the auction, stock symbol/price, and word of the day, respectively).

Thanks to Brian Slesinsky, who graciously trilicensed XPath Checker code, the prototype also supports user-defined microsummaries. Just context-click on some text in a page, then select "Watch [the text]" from the context menu. The prototype will add a bookmark to your bookmarks toolbar whose title is the text you clicked on, then it'll update it regularly.

Here's a screenshot which demonstrates microsummaries for the three built-in types plus a user-defined microsummary (the number of lines changed in a Bonsai query for "Places checkins in the last day"):

Note that this is an early prototype. It has limited functionality, lots of bugs, and relies on the rapidly evolving Places code (so is susceptible to bustage). Don't rely on it or expect any eventual Firefox feature to work like it. It's just a proof of concept.

Also note that it'll take up to 15 seconds for a bookmark you add to the toolbar to start showing a microsummary. After that, the extension will update the microsummary every 30 minutes.

Finally, note that Places mucks with your profile, migrating history and bookmarks to new databases. Make sure you know what you're doing (or are using a fresh profile) when you try out a Places-enabled build.

If I haven't scared you away yet, then give it a try, and let me know what you think.

Microsummarizer 0.1

resigning Bugzilla UI module ownership

2006-02-02T15:30:00.000-08:00

I recently came to the realization that I don't have the time to function as an effective UI module owner for Bugzilla, so I have resigned that position.

Bugzilla's UI module owner needs to encourage good usability improvements, deflect misguided changes and unintentional regressions, and keep usability central to the development process.

Although coding can be involved, the role isn't primarily about writing code. It's about examining and intuiting user needs and behavior, determining how well the current UI meets those needs and supports that behavior, proposing and evaluating beneficial changes, and engaging the development community with reviews and discussion.

I wanted to do a lot of usability work in the last year, but for a variety of reasons I ended up doing only a small amount, and I expect to have very little time to do this work in the future. I'll continue to contribute where I can, of course, and I wish the project the best of luck with its UI development efforts.

If you're interested in helping out with Bugzilla UI development, watch the ui@bugzilla.bugs user on bugzilla.mozilla.org and join the conversations on the mozilla.dev.apps.bugzilla newsgroup and the developers@bugzilla.org mailing list.

son of live bookmarks

2006-01-11T16:52:00.000-08:00

I buy about a dozen items per year on eBay, and when I'm bidding on an item, I add its bookmark to my personal toolbar, then I click that bookmark repeatedly for the duration of the auction just to find out two simple pieces of information: the current bid and the time left.

Instead of making me click the link over and over to get that information, Firefox should automatically check the auction periodically on my behalf and add its status to the bookmark label. Then I could keep track of the auction just by glancing at my personal toolbar.

Auctions may be my personal itch, but I reckon there are other auctioneers with the same itch, and a feature like this could be handy elsewhere, too. A bookmark to an Amazon product could display the product's current price, for example, while a bookmark to a news site could show its latest headline. Basically, any page with important and regularly-updated but short summary information is a candidate for this feature.

It might even be useful to display these summaries in other places--like tabs and window title bars--where the browser currently displays page titles. And it might make sense to define a simple microformat to let the pages themselves specify which of their content represents summary information and how often to update it, although we'd want to allow users to override that where appropriate, just as we let them choose their own bookmark labels.

This feature extends a concept that live bookmarks introduced: that bookmarks can display much more than just static links to locations, they can display regularly-updated summaries of those sites. So I'll call this "son of live bookmarks," for lack of a better name, and in homage to the same cheesy horror flicks from which Mozilla derived its name.

Would you use this feature if it was available? Can you think of other kinds of pages for which the feature would come in handy? Got a better name for it? Comments welcome.